La bibliothèque OpenSSL est encore une fois victime d'une importante faille de sécurité. Seules les versions des branches 1.0.1 et 1.0.2 datant de moins d'un mois sont concernées, une mise à jour est d'ores et déjà disponible.
Le 6 juillet, OpenSSL diffusait un bulletin de sécurité plutôt inquiétant afin d'indiquer qu'une faille de sécurité avec un haut niveau de gravité avait été découverte. Des mises à jour étaient annoncées pour aujourd'hui et elles viennent d'être mises en ligne. Elles sont estampillées 1.0.1p et 1.0.2d.
Les notes de versions permettent d'en apprendre un peu plus sur les tenants et les aboutissants de cette histoire qui, après le douloureux épisode Heartbleed, avait de quoi préoccuper. « Lors de la vérification d'un certificat, OpenSSL (à partir de la version 1.0.1n et 1.0.2b) va tenter de trouver une chaîne de certification de remplacement si la première tentative échoue. Mais, une erreur dans sa mise en œuvre peut permettre à un attaquant d'outrepasser certaines vérifications sur des certificats non approuvés, comme celui de l'autorité de certification », explique OpenSSL. Problème, cela peut conduire à accepter un certificat non valide édité par une personne qui intercepte la communication.
OpenSSL indique que cette brèche avait été remontée le 24 juin dernier par Adam Langley et David Benjamin qui s'occupent tous les deux de BoringSSL, une implémentation maison d'OpenSSL développée par Google. Le correctif a été développé par BoringSSL avant d'être intégré à OpenSSL.
Il est donc recommandé de se mettre à jour si vous êtes sur l'une des versions touchées par cette faille : OpenSSL 1.0.1n, 1.0.1o, 1.0.2b et 1.0.2c. Ces quatre moutures ont été mises en ligne il y a moins d'un mois maintenant, on est donc loin d'être dans le cas de Heartbleed qui touchait bien plus de versions, avec une facilité de mise en œuvre bien plus grande.
Red Hat s'est d'ailleurs fendu d'un billet afin d'indiquer qu'« aucun de ses produits n'est affecté par cette faille (CVE-2015-1793), il n'y a donc pas de mesures à prendre pour corriger ou limiter cette brèche ». D'autres sociétés devraient suivre dans les heures qui viennent, que ce soit pour annoncer une mise à jour ou rassurer ses utilisateurs.
Commentaires (32)
#1
Mouais le code de openSSL est franchement crado. Faudrait voir pour réécrire tout ça proprement, plutôt que de plâtrer la chose.
#2
C’est le but des 2 forks en cours : BoredSSL (Google) et LibreSSL (OpenBSD)
" />
De mémoire, le code de LibreSSL est déjà compilable sous Linux et est parfaitement rétro compatible OpenSSL
#3
Dommage de voir de telles failles, surtout dans une bibliothèque utilisée aussi largement.
Enfin l’important est qu’elle ait été rapidement patchée.
#4
Ca sent la mise à jour Synology très bientôt, il me semble que OpenSSL avait été mis à jour en version 1.01o.
#5
ça sent surtout les mise à jour de 90% des serveurs et même clients ssl…
C’est toujours aussi massif.
#6
#7
#8
Ho ben non, je viens de passer la nuit à faire rentrer OpenSSL dans Nginx de force, faut tout recommencer maintenant
" />
#9
Pas du tout ! la plupart des serveurs ne tournent pas sur une version aussi récente (la 1.0.1n date du 11 Juin 2015)
exemple sur Debian Stable:
$ openssl version
OpenSSL 1.0.1k 8 Jan 2015
#10
A croire que quand bien même les sources soient accessibles, personnes n’a pris la peine de vraiment les vérifier… Pourtant, c’est pas comme si la bibliothèque était utilisé un peu partout et par un peu tout le monde et qu’elle était un point critique dans la sécurité.
#11
#12
#13
#14
#15
Openssl is written by monkeys
#16
#17
C’est souvent le problème que rencontre le libre : beaucoup utilisé mais pas forcément épaulé.
#18
Si tu es sur une Debian stable (1.0.1k pour l’instant) -> pas concerné :)
#19
#20
Tu te proposes donc pour faire un audit complet et parfait d’OpenSSl ?
" />
Ça c’est gentil, merci
#21
C’est ballot, j’ai piscine… heu mon docteur m’a interdit de faire des audit.
Non, plus sérieusement, chacun son métier, chacun ses compétences, et l’audit en sécurité, ce n’est pas mon truc. Je ne serait même pas capable de trouver une faille dans flash même si on me donnerait son code source.
#22
#23
#24
#25
J’adore le mec qui me fait dire ce que je n’ai pas dit: “faites le vous même” et “et pourquoi ne l’avez vous pas fait” ont un sens bien différent. Contrairement à ce que tu disais, il n’est pas “difficile de savoir ce qui s’est passé exactement”: on le sait, ton commentaire l’indique d’ailleurs, tout comme je l’avais fait initialement, en plus court certes.
#26
l’humulité ça à du bon des fois, tu devrait t’en inspirer
" />
#27
Quand je vous lis, ça donne l’impression qu’il y a des gens qui relisent le code écrit par les autres
" /> c’est assez logique
" />
J’ai déja vu ça en cas de problème des milliers de fois
J’ai déja vu ça à l’école
J’ai vu cela quand quelqu’un cherchait à pomper une idée ( pourquoi pas)
J’ai déja vu ça sur quelques petits morceaux quand des audits essaient de planter certaines fonctions
( et encore très rarement)
Pour améliorer les perf ( très souvent)
Mais je n’ai jamais encore vu de ma vie du code écrit par quelqu’un et relu par un autre pour soi-disant “le valider” ,” le controller” ou “l’auditer”
Ai je vécu dans un monde parallèle pendant tout ce temps ?
#28
En parlant d’OpenBSD, suite à l’intégration d’OpenSSH dans Windows 10, Microsoft a décidé de devenir le tout premier Gold contributor de l’OpenBSD Foundation ;)
Sinon, pour BoringSSL ou LibreSSL, on verra si ça donne quelque chose de bien un jour, mais pour le moment, ce ne sont que des forks, de la division de moyens…
Pour le moment, si on a enfin pu attribuer des moyens financiers à OpenSSL et à d’autres projets cruciaux, c’est avant tout grâce à la Linux Foundation et à sa Core Infrastructure Initiative.
#29
#30
#31
#32