Connexion
Abonnez-vous

OpenSSL : nouvelle mise à jour pour une faille critique

Bientôt l'alphabet ne sera plus assez grand

OpenSSL : nouvelle mise à jour pour une faille critique

Le 09 juillet 2015 à 14h37

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)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

ça sent surtout les mise à jour de 90% des serveurs et même clients ssl…

 



C’est toujours aussi massif.

votre avatar







John Shaft a écrit :



C’est le but des 2 forks en cours : BoredSSL (Google) et LibreSSL (OpenBSD) <img data-src=" />



De mémoire, le code de LibreSSL est déjà compilable sous Linux et est parfaitement rétro compatible OpenSSL



Pquoi ce nom ne m’étonne même pas venant de GG? <img data-src=" />


votre avatar







Patch a écrit :



Pquoi ce nom ne m’étonne même pas venant de GG? <img data-src=" />







Correctif, c’est BoringSSL et non Bored <img data-src=" />



Enfin le sens est quasi identique <img data-src=" />



Je crois d’ailleurs que les 2 forks sont nés après HeartBleed


votre avatar

Ho ben non, je viens de passer la nuit à faire rentrer OpenSSL dans Nginx de force, faut tout recommencer maintenant <img data-src=" />

&nbsp;

votre avatar

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


votre avatar

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é.

votre avatar







tazvld a écrit :



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é.







Le code est bien vérifié, et par plusieurs yeux qui plus est, mais c’est complexe de détecter une faille, ça ne se fait pas en lisant le code source. Que le code soit ouvert ou fermé, ça ne garantit pas du tout l’absence de failles.



Le fait que le code soit ouvert permet surtout que la faille soit corrigée rapidement : en l’occurrence c’est d’abord Google qui a proposé un patch dans BoringSSL, et ce patch a ensuite été repris dans OpenSSL et LibreSSL.


votre avatar







Konrad a écrit :



Le code est bien vérifié, et par plusieurs yeux qui plus est, mais c’est complexe de détecter une faille, ça ne se fait pas en lisant le code source. Que le code soit ouvert ou fermé, ça ne garantit pas du tout l’absence de failles.



Le fait que le code soit ouvert permet surtout que la faille soit corrigée rapidement : en l’occurrence c’est d’abord Google qui a proposé un patch dans BoringSSL, et ce patch a ensuite été repris dans OpenSSL et LibreSSL.





De ce que j’ai compris d’Heartbleed, ça m’avais tout l’air d’un problème des plus basiques de chaîne de caractère en C. C’est scolaire comme problème pourtant (toujours vérifier que la position d’accès dans un tableau et ne jamais faire confiance à l’utilisateur). C’est pour ça, je me dis que c’est vraiment étonnant que ça eut pu passer. Et que cette faille est déjà été trouvé par la NSA (et surement d’autres agences), c’est pas des sur-hommes à la NSA, leur compétences restent humaines, un audite parmi les 10aines que ce code aurait dû normalement avoir subit vu son importance stratégique, putain, personne n’a sortie cette erreur ?!


votre avatar







John Shaft a écrit :



Correctif, c’est BoringSSL et non Bored <img data-src=" />



Enfin le sens est quasi identique <img data-src=" />



Je crois d’ailleurs que les 2 forks sont nés après HeartBleed



Oui l’un ou l’autre c’est équivalent au final <img data-src=" />


votre avatar







tazvld a écrit :



De ce que j’ai compris d’Heartbleed, ça m’avais tout l’air d’un problème des plus basiques de chaîne de caractère en C. C’est scolaire comme problème pourtant (toujours vérifier que la position d’accès dans un tableau et ne jamais faire confiance à l’utilisateur). C’est pour ça, je me dis que c’est vraiment étonnant que ça eut pu passer. Et que cette faille est déjà été trouvé par la NSA (et surement d’autres agences), c’est pas des sur-hommes à la NSA, leur compétences restent humaines, un audite parmi les 10aines que ce code aurait dû normalement avoir subit vu son importance stratégique, putain, personne n’a sortie cette erreur ?!







Oui je suis d’accord ça la fout mal.

Difficile de savoir ce qui s’est passé exactement.


votre avatar
votre avatar







Konrad a écrit :



Oui je suis d’accord ça la fout mal.

Difficile de savoir ce qui s’est passé exactement.







Ce qu’il s’est passé c’est que des dizaines de milliers d’entreprise utilisent openSSL pour générer des milliards de dollars de chiffre d’affaire mais pas une seule est foutue d’y mettre 1 développeur 1 jour par mois…



OpenSSL c’est… 1 salarié à temps plein !


votre avatar

C’est souvent le problème que rencontre le libre : beaucoup utilisé mais pas forcément épaulé.

votre avatar

Si tu es sur une Debian stable (1.0.1k pour l’instant) -&gt; pas concerné :)

votre avatar







Diom a écrit :



Ce qu’il s’est passé c’est que des dizaines de milliers d’entreprise utilisent openSSL pour générer des milliards de dollars de chiffre d’affaire mais pas une seule est foutue d’y mettre 1 développeur 1 jour par mois…



OpenSSL c’est… 1 salarié à temps plein !







Merci. Les “y’a qu’à” “faut qu’on” sont fatigants. Si c’est si simple et facile, pourquoi vous l’avez pas fait les gars ? La réalité c’est que c’est complexe et coûteux et personne n’a investi dans ce code depuis des années. Tout le monde s’est réveillé lors d’heartbleed!


votre avatar

Tu te proposes donc pour faire un audit complet et parfait d’OpenSSl ?



Ça c’est gentil, merci <img data-src=" />

votre avatar

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.

votre avatar







tazvld a écrit :



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.





Facile pour ton exemple pourtant : tu imprimes tout ou partie du code, tu étends les feuilles devant toi, tu te bandes les yeux et laisses ton doigt tomber au pif.

Statistiquement, tu devrais avoir trouvé une faille <img data-src=" />


votre avatar







zepompom a écrit :



Merci. Les “y’a qu’à” “faut qu’on” sont fatigants. Si c’est si simple et facile, pourquoi vous l’avez pas fait les gars ? La réalité c’est que c’est complexe et coûteux et personne n’a investi dans ce code depuis des années. Tout le monde s’est réveillé lors d’heartbleed!





Oui bon OK c’est sûr.

Mais il y a quand même une petite différence entre faire ca chez soi tranquillement en tant que particulier, et qu’une société privée qui utilise le service paie un de ses devs pros à essayer d’optimiser un outil que la boite en question utilise tous les jours…



Moi ce qui me surprend c’est que l’OpenSSL soit si utilisé pur une application aussi critique, et que personne de professionnel n’ait mis le nez dedans rien que pour jeter un oeil….


votre avatar







zepompom a écrit :



Merci. Les “y’a qu’à” “faut qu’on” sont fatigants. Si c’est si simple et facile, pourquoi vous l’avez pas fait les gars ?







J’adore le mec qui se plaint des « y’a qu’à faut qu’on », et qui derrière dit « vous n’avez qu’à le faire vous-mêmes » <img data-src=" />



J’utilise pas mal de logiciels libres, j’en ai même développé un petit moi-même, avant tout pour mes propres besoins.



Il y a des entreprises qui intègrent véritablement des logiciels libres : elles ne font pas qu’utiliser, elles y contribuent, soit en temps de développement (en embauchant ou en payant des dev), soit en versant de l’argent à des fondations, soit en fournissant des machines, etc. les moyens de contribuer sont multiples.



En revanche beaucoup d’entreprises « pillent » les logiciels libres, c’est-à-dire qu’elles ne font que les télécharger et les utiliser, elles basent leur business dessus sans jamais rien donner en retour. J’ai un peu peur que ce soit ce qui s’est passé avec OpenSSL : tout le monde a bien profité du travail du développeur isolé, personne n’a contribué, par contre quand on trouve un problème tout le monde se plaint.



Il a fallu HeartBleed pour découvrir à quel point la situation était critique, heureusement les choses changent et de grosses équipes commencent à faire véritablement bouger les choses : Google avec BoringSSL, OpenBSD avec LibreSSL.



Au final la sécurité de ces librairies SSL devraient être renforcées, le code devrait être plus propre et plus facile à maintenir, et mieux audité.


votre avatar

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.

votre avatar

l’humulité ça à du bon des fois, tu devrait t’en inspirer <img data-src=" />

votre avatar

Quand je vous lis, ça donne l’impression qu’il y a des gens qui relisent le code écrit par les autres

J’ai déja vu ça en cas de problème des milliers de fois

J’ai déja vu ça à l’école <img data-src=" /> c’est assez logique

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 ?

<img data-src=" />

votre avatar

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.

votre avatar







JoePike a écrit :



Quand je vous lis, ça donne l’impression qu’il y a des gens qui relisent le code écrit par les autres

J’ai déja vu ça en cas de problème des milliers de fois

J’ai déja vu ça à l’école <img data-src=" /> c’est assez logique

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 ?

<img data-src=" />







La revue de code est pourtant pratiquée par endroits, voire recommandée quand les impératifs de qualité le nécessitent il me semble


votre avatar







dj0- a écrit :



La revue de code est pourtant pratiquée par endroits, voire recommandée quand les impératifs de qualité le nécessitent il me semble







<img data-src=" /> et <img data-src=" />

Je n’ai pas parlé de revue de code mais de relecture de code

C’est pas la même chose du tout

La revue de code et ses réunions c’est une chose , il y a des outils automatiques , des vérifs de specs , des investigations sur les perfs etc etc …

mais de la relecture systématique j’ai jamais vu.



votre avatar







Okki a écrit :



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 ;)







Une excellente nouvelle : une entreprise qui emploie un logiciel libre, qui va y contribuer, et qui donne des sous à la fondation mère.



À mon avis, d’autres grosses boîtes devraient en prendre de la graine, à commencer par Google, Apple, Facebook, Amazon…


votre avatar







douda_wak a écrit :



l’humulité ça à du bon des fois, tu devrait t’en inspirer <img data-src=" />





La grammaire et l’orthographe aussi, 3 fautes en une phrase, tu m’excuseras de ne pas te prendre au sérieux <img data-src=" />


votre avatar

Mouais le code de openSSL est franchement crado. Faudrait voir pour réécrire tout ça proprement, plutôt que de plâtrer la chose.

votre avatar

C’est le but des 2 forks en cours : BoredSSL (Google) et LibreSSL (OpenBSD) <img data-src=" />



De mémoire, le code de LibreSSL est déjà compilable sous Linux et est parfaitement rétro compatible OpenSSL

votre avatar

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.

votre avatar

Ca sent la mise à jour Synology très bientôt, il me semble que OpenSSL avait été mis à jour en version 1.01o.

OpenSSL : nouvelle mise à jour pour une faille critique

Fermer