#repatch

Fin septembre, les équipes du projet OpenSSL émettaient un correctif pour une vulnérabilité de sévérité limitée. Celle-ci pouvait être utilisée pour provoquer un déni de service par surconsommation de mémoire vive. Las, le remède s’est avéré plus dangereux que le mal : une autre vulnérabilité, critique cette fois-ci, est apparue, pouvant être exploitant pour forcer l’exécution à distance de code arbitraire.

De manière exceptionnelle, les équipes du projet ont contourné leur processus habituel pour l’annonce de vulnérabilités et la mise à disposition de correctifs pour en distribuer un nouveau, dans l’urgence.

Et de reconnaître que « cette mise à jour de sécurité corrige des problèmes causés par les rustines intégrées à notre précédente mise à jour de sécurité, distribuée le 22 septembre 2016. Compte tenu de la sévérité critique de l’une de ces failles, nous avons décidé de diffuser cette alerte immédiatement pour prévenir les mises à niveau version affectée ».

De fait, on imagine aisément l’exaspération d’administrateurs ou d’éditeurs et constructeurs utilisant la librairie et devant soit déployer eux-mêmes, soit diffuser deux mises à jour consécutives, la seconde corrigeant des vulnérabilités générées par la première.

De quoi également apporter de l’eau au moulins de tous ceux qui préfèrent attendre, parfois longtemps, très voire trop longtemps, pour déployer les correctifs de sécurité. Et les mauvaises habitudes de gestion des correctifs ne semblent pas avoir besoin d’encouragements.

Go to Source