Connexion
Abonnez-vous

OpenSSL corrige une importante faille qui permettait de récupérer les clés de chiffrement

Une pointe de laxisme dans la configuration par défaut

OpenSSL corrige une importante faille qui permettait de récupérer les clés de chiffrement

Le 30 janvier 2016 à 09h00

L’équipe en charge d’OpenSSL propose depuis peu un correctif colmatant une importante brèche de sécurité. Le temps de correction a été particulièrement court, la vulnérabilité ayant été signalée le 12 janvier. Lors de l’avertissement, une rustine partielle était cependant déjà en cours de validation.

L’OpenSSL Software Foundation a mis à disposition hier une nouvelle version d’OpenSSL. Cette mouture règle un sérieux problème de sécurité qui, s’il devait être exploité, permettrait de déchiffrer les communications transitant sur une connexion HTTPS ou n’importe quel canal TLS (Transport Layer Security). La faille est d’autant plus dangereuse qu’OpenSSL est largement utilisé.

Un problème de réutilisation des clés

Cependant, son exploitation n’est pas simple à proprement parler. Plusieurs conditions doivent en effet être réunies, dont la plus importante est l’utilisation obligatoire de la version 1.0.2, les autres n’étant pas sensibles à cette faille. Les applications se servant d’OpenSSL 1.0.2 doivent en outre utiliser des groupes basés sur le DSA (Digital Signature Algorithm) pour générer des clés éphémères fondées sur le modèle d’échange Diffie-Hellman. Mais, par défaut, ce comportement rend les serveurs vulnérables à des attaques visant la récupération des clés car ils réutilisent les mêmes nombres premiers à chaque fois.

Dans le cas où ces conditions sont réunies, des attaquants pourraient bombarder de requêtes un serveur ou un ordinateur personnel. À force d’insister, la montagne de calcul finit par révéler des fragments d’informations, qui peuvent éventuellement être recombinés via le « théorème des restes chinois », formant alors la clé de déchiffrement.

De nombreuses applications n'utilisent pas la configuration par défaut

Mais, comme indiqué, la faille n’est pas simple à exploiter. De nombreuses applications utilisent un autre type de configuration par défaut, à l’instar du Web Server d’Apache. Des bibliothèques dérivées d’OpenSSL, comme BoringSSL et LibreSSL, n’y sont pas non plus sensibles. Cependant, l’ensemble peut être vulnérable si un utilisateur se sert d’une suite cryptographique statique, favorisant ainsi la réutilisation des clés.

La faille, portant la référence CVE-2016-0701, a fait hier l’objet d’un billet de blog de la part de son découvreur, Antonio Sanso, chercheur chez Adobe. Elle a été signalée le 12 janvier de manière privée, montrant ainsi la célérité avec laquelle l’équipe d’OpenSSL s’est chargée de développer le correctif. Il est possible toutefois que le travail ait été grandement facilité par un patch partiel en cours de validation, car certains aspects de la faille avaient découvert un peu plus tôt. C’est toutefois le travail de Sanso qui a montré l’ampleur du problème.

La version 1.0.2f corrige le problème

Une nouvelle version d’OpenSSL est donc disponible au téléchargement. Estampillée 1.0.2f, elle corrige la faille et active également l’option « SSL_OP_SINGLE_DH_USE » par défaut (en ne laissant pas la possibilité de la désactiver), permettant à la génération de clés d’utiliser des nombres premiers différents à chaque fois. Dans tous les cas, cela peut avoir des impacts sur les performances prévient OpenSSL.

Notez dans le même temps que l’OpenSSL Software Foundation a également publié la mouture 1.0.1r qui corrige d’autres soucis de sécurité. Elle rappelle dans un message que cette version 1.0.1 verra dans tous les cas son support s’arrêter au 31 décembre 2016. Il n’y aura plus aucun correctif de sécurité pour cette branche, la fondation enjoignant les utilisateurs à basculer sur la 1.0.2 dès qu’ils le pourront.

Commentaires (40)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Bon, limité à DSA, DHE et OpenSSL 1.0.2, ça limite les dégâts quand même

votre avatar

Ben, non, justement cela permet d’éviter que l’on utilise toujours les même clefs. Si elles restent toujours les mêmes, il suffit d’écouter un plus grand volume de données pour décoder les communications.

votre avatar







Z-os a écrit :



Ben, non, justement cela permet d’éviter que l’on utilise toujours les même clefs. Si elles restent toujours les mêmes, il suffit d’écouter un plus grand volume de données pour décoder les communications.





Ou pas … le temps de déchiffrement des données reste le même c’est juste la quantitée de données qui sera déchiffrée un jour qui sera plus volumineuse. Cherche le concept de la pfs dans  ipsec ca te parlera peut être …



OpenSSL est une library archaique digne dprovider de clé legacy chez MS dans la crypto api, il est plus que temps d’enterrer cette bouse comme l’a fait l’equipe OpenBSD et OpenSSH en la forkant pour créer LibreSSL.


votre avatar

Je vais me recycler en migration de la couche sécurité en entreprise moi.

votre avatar

C’est nice de traiter de “bouse” un composant utiliser par autant de personne et développer par une bande de personne qui offre leur temps gratuitement.



Je trouve ça toujours très drôle le reniement que les devs et assimiler peuvent montrer parfois.

votre avatar



Antonio Sanso, chercheur chez Adobe.





Apparemment chez Adobe on est capable de trouver des failles chez les autres mais difficilement dans certains de leurs propres produits comme par exemple Flash… <img data-src=" />

votre avatar

non chez adobe, ils connaissent leur failles mais les laisse exprès, c’est différent! <img data-src=" />

votre avatar

Vous avez déjà utilisé cette OpenSSL ?

Parce que clairement c’est une saloperie sans nom, le code est dégueulasse et les perfs sont loin d’être au top!



Le fait que ce soit utilisé par tant de monde n’en fait pas un bon produit, ou alors IE 6 était une merveille ^_^’

Si elle a été tant utilisé c’est surtout sur base du principe qui veut que “c’est open, ça vient du monde libre donc c’est bon, mieux, c’est de la bombe!”

Malheureusement les gens perdent souvent leur sens critique dès qu’il s’agit du monde libre sur ce seul prétexte…

&nbsp;

votre avatar

Le libre c’est bon. Mangez en. <img data-src=" />

votre avatar

Je rajouterais également que concernant la cryptographie, on met en œuvre des algos mathématiquement pointus, et qu’il ne suffit pas d’être un bon développeur pour en détecter les failles potentielles, mais également un bon théoricien.

votre avatar

Le problème est aussi que la cryptographie (la sécurité en général) est un domaine très particulier.

Implémenter une norme, c’est une chose.

Implémenter une norme utilisée en sécurité en s’assurant que l’implémentation est robuste aux attaques « side-channel » (je n’ai plus le terme français en tête), c’est autre chose.

OpenSSL, même si ses perfs ne sont pas au top, est assez résistant à ce type d’attaque du fait de son implémentation.



La plupart des boîtes n’ont pas les compétences pour faire une bibliothèque de sécurité, donc elles font appel à un prestataire externe.

Pour une question financière, elles vont souvent prendre un logiciel public (et encore, certains produits commerciaux sont eux-même basés sur OpenSSL et ajoutent juste une couche supplémentaire).

Pour des raisons de licence, certains logiciels seront éliminés (GNUTLS, par exemple).



La règle numéro 1 en crypto (quand ce n’est pas ta spécialité), c’est « ne définit pas d’algorithme de cryptographie quel qu’il soit ».

La règle numéro 2, c’est « n’implémente pas d’algorithme de cryptographie quel qu’il soit ».

votre avatar

La règle numéro 3, c’est « ne prends pas n’importe quel prestataire »

votre avatar







papinse a écrit :



Implémenter une norme utilisée en sécurité en s’assurant que l’implémentation est robuste aux attaques « side-channel » (je n’ai plus le terme français en tête), c’est autre chose.





Je crois qu’on parle de canal auxiliaire, cffr.wikipedia.org Wikipedia.


votre avatar

Oui, c’est ça, merci.







levhieu a écrit :



La règle numéro 3, c’est « ne prends pas n’importe quel prestataire »



Je ne peux qu’approuver. <img data-src=" />


votre avatar

Ce qui m’étonne toujours dans les histoires de failles, c’est que les développeurs ne fassent pas correctement le travail correctement avant la mise à disposition du public.

A moins que les failles apparaissent spontanément avec de nouveaux outils d’attaques, je trouve ça un peu léger.

votre avatar

Ce sont simplement des systémes tellement complexes que même en effectuant des wagons de vérification, il n’est jamais possible de tout vérifier, ni même de tout imaginer.&nbsp;

Quand tu regarde, l’exploitation de ces failles est rarement simple à mettre en œuvre, et ce sont généralement des comportements soit complètement alambiqué, soit des dépassements de valeurs concidéré comme haute à une époque qui sont à l’origine de ces failles.

votre avatar







slow brain a écrit :



Ce sont simplement des systémes tellement complexes que même en effectuant des wagons de vérification, il n’est jamais possible de tout vérifier, ni même de tout imaginer.&nbsp;

Quand tu regarde, l’exploitation de ces failles est rarement simple à mettre en œuvre, et ce sont généralement des comportements soit complètement alambiqué, soit des dépassements de valeurs concidéré comme haute à une époque qui sont à l’origine de ces failles.





Je rejoins complétement slow brain. Gros projet ultra complexe niveau code et opensource (ils ont pas les mêmes ressources financières qu’un microsoft pour les tests).


votre avatar

C’était pas une faille, c’était une feature pour la NSA.

votre avatar

Ha oui, ceci explique cela…

votre avatar

Debian Jessie est restée à la version 1.0.1, ça laisse le temps de voir venir <img data-src=" />. L’intégration du correctif CVE-2015-3197 ne devrait pas tarder.

votre avatar

Ton message est la preuve qu’une faute est vite commise. Correctement ou correctement ? :)

votre avatar

Au debut du software années 60, 70 80) on considérait qu’il y avait en moyenne 1 erreur par ligne de code dans la vie d’un produit ( chiffres issus de statistiques )

Les langages n’étaient pas évoluées et complexes à utiliser

les boites partaient du principe que sur 1 million de lignes il y avait 100000 erreurs ( ponctuation logique pointage vers le sud etc …)

donc on notait toutes les erreurs même les virgules oubliées et quand le chiffre d’erreur trouvées atteignait les 90% ( dans notre cas 90000 erreurs répertoriées et corrigées ) le produit était release au public.

La raison était que le coût de la panne touvée augmentait trop avec le temps ( virgule trouvée en 3 secondes la 85 millième panne de logique qui prend 3 semaines etc …

Donc a un moment il fallait arrêter les frais …



Depuis quelques années les langages sont devenus plus simples et on a commencé à bosser en mode projet … avec target date de mise à dispo du public ou autre quota de pannes résolues par semaine etc …

le système a changé le nombre de pannes aussi (j’ai pas de chiffres aujourd’hui) mais il reste qu’on ne peut jamais trouver

toutes les failles dans le code dans un temps défini. Il en reste toujours !



J’ai parlé en général et pas sur le bug décrit dans l’article, mais uniquemen,t pour pour répondre en partie à ta question.

<img data-src=" />

votre avatar

Il y a un truc très con aussi : OpenSSL a longtemps manqué d’argent, et n’a jamais eu les moyens de nettoyer son code, ni de le réécrire. Alors qu’OpenSSL est utilisé depuis longtemps par la très grosse majorité du web. Après la faille HeartBleed, les géants du net se sont enfin réveillés. Mais OpenSSL est basé sur un code ancien et complexe.



Après l’affaire HB, OpenBSD avait lancé un fork, LibreSSL. Le nettoyage du code a été la première tâche lancée, et autant dire que ça se faisait à la tronçonneuse.



C’est le paradoxe du Libre actuel : des briques ultra vitales pour le monde informatique, mais maintenues par très peu de gens, parfois même une seule personne, sans moyens et sans aide des acteurs qui utilisent massivement cette solution (que ce soit en retour de bugs corrections, ou financièrement). OpenSSL n’est que le premier à être aussi visible, et il sera loin d’être le dernier.

votre avatar

J’ai pas compris grand chose, mais juste l’essentel : c’est vite corrigé <img data-src=" />

(je n’ai pas plus compris les références vers Wikipédia <img data-src=" />)

votre avatar

<img data-src=" />

Surtout quand on prend comme exemple Alice et Bob alors qu’on s’appelle Whitfield et Martin

des vicieux ces mecs !

<img data-src=" />

votre avatar

Et après il y en a encore pour vanter l’ “open”, ce monde de bandes d’amateurs baba-cool de l’informatique, par rapport au monde certes “fermé et propriétaire” mais qui est composé de professionels, avec les moyens qu’il faut, et qui d’ailleurs n’expose pas son code source donc cache ses failles éventuelles aux pirates.

votre avatar

Si ça n’était pas un troll ça aurait été intéressant d’y répondre.

votre avatar







Exception a écrit :



Et après il y en a encore pour vanter l’ “open”, ce monde de bandes d’amateurs baba-cool de l’informatique, par rapport au monde certes “fermé et propriétaire” mais qui est composé de professionels, avec les moyens qu’il faut, et qui d’ailleurs n’expose pas son code source donc cache ses failles éventuelles aux pirates.





jvachez seal of approval&nbsp;<img data-src=" />


votre avatar

Si c’est un troll, c’est vachement bon ! Quasi indétectable.

votre avatar

Vous n’avez pas compris ou vous vivez dans le monde de bisounours?

La plupart des failles ont été creer pour servir les gouvernements et services secret , comme les hardwares routeurs cisco etc..

Pas besoin d’etre ingénieur pour comprendre.

votre avatar

CS est demandé sur la news OpenSSL…

votre avatar







code a écrit :



Vous n’avez pas compris ou vous vivez dans le monde de bisounours?

La plupart des failles ont été creer pour servir les gouvernements et services secret , comme les hardwares routeurs cisco etc..

Pas besoin d’etre ingénieur pour comprendre.





peut être que si en fait il faut être ingénieur pour comprendre….


votre avatar







Quiproquo a écrit :



Si c’est un troll, c’est vachement bon ! Quasi indétectable.







Tout en subtilité

<img data-src=" />


votre avatar







code a écrit :



Vous n’avez pas compris ou vous vivez dans le monde de bisounours?

La plupart des failles ont été creer pour servir les gouvernements et services secret , comme les hardwares routeurs cisco etc..

Pas besoin d’etre ingénieur pour comprendre.







Il n’y a pas de mauvais développeurs, il n’y a que de bons agents infiltrés.


votre avatar







127.0.0.1 a écrit :



Il n’y a pas de mauvais développeurs, il n’y a que de bons agents infiltrés.





Ho purée, génial ! Si mon boss gueule que j’ai laissé un bug dans l’app, je pourrais dire que j’ai été payé par Fort Meade&nbsp; <img data-src=" />


votre avatar

paske tu ne l’es pas encore ????



pff le loser !



<img data-src=" />

votre avatar







JoePike a écrit :



paske tu ne l’es pas encore ????



pff le loser !



<img data-src=" />



Moi non mais mon collègue est bizarre ces temps si, il parle en anglais sur son mobile et chiffre ses mails..Surement un espion….&nbsp; Vu que je lorgne sur une promotion, je ferais ptet bien de le dénoncer au boss et à Manuel Valls


votre avatar







Quiproquo a écrit :



Si c’est un troll, c’est vachement bon ! Quasi indétectable.





Ça se saurait si le fermé / propriétaire était mieux loti pour la sécu préventive et curative par rapport à l’open source.


votre avatar

“Estampillée 1.0.2f, elle corrige la faille et active&nbsp;également l’option

«&nbsp;SSL_OP_SINGLE_DH_USE&nbsp;» par défaut (en ne laissant pas la possibilité

de la désactiver), permettant à la génération de clés d’utiliser des

nombres premiers différents à chaque fois.”



Option non désactivable. Je ne comprends pas que tout le monde applaudisse.

&nbsp;Ça ce n’est pas de la sécurité.

votre avatar

C’est hallucinant de voir le nombre de gens qui tirent des conclusions complètement erronées d’une telle news. C’est pourquoi je pense que dans un tel article, le contexte devrait être mieux expliqué pour le profane. Parce qu’un non informaticien n’a aucune chance de se faire une idée valable.



D’abord, parlons d’un paradoxe : quand on découvre des failles dans un logiciel dont le code est autant scruté, c’est bien parce qu’il y a des personnes qui ont travaillé très dur à cela. C’est plutôt un signe de sérieux et de bonne santé.









Moff Tigriss a écrit :



Il y a un truc très con aussi : OpenSSL a longtemps manqué d’argent, et n’a jamais eu les moyens de nettoyer son code, ni de le réécrire. Alors qu’OpenSSL est utilisé depuis longtemps par la très grosse majorité du web. Après la faille HeartBleed, les géants du net se sont enfin réveillés. Mais OpenSSL est basé sur un code ancien et complexe….







Jusqu’à l’hyper médiatisation de cette faille, ce composant n’avait pas tellement fait parler de lui. Depuis, de grands acteurs y ont consacré des moyens. D’ou paradoxalement le fait qu’on y découvre de nouvelles failles. Ce qui est encore une fois plutôt bon signe.







YesWeekEnd a écrit :



Ça se saurait si le fermé / propriétaire était mieux loti pour la sécu préventive et curative par rapport à l’open source.







Clairement.



D’ailleurs, comme bien souvent dans le libre, la rapidité avec laquelle la faille est corrigée est exemplaire.







Exception a écrit :



Et après il y en a encore pour vanter l’ “open”, ce monde de bandes d’amateurs baba-cool de l’informatique, par rapport au monde certes “fermé et propriétaire” mais qui est composé de professionels, avec les moyens qu’il faut, et qui d’ailleurs n’expose pas son code source donc cache ses failles éventuelles aux pirates.







D’abord, contrairement à une idée reçue, la plupart des programmeurs du libre sont des pro, c’est à dire des informaticiens chevronnés et expérimentés. Et bien souvent, ils sont aussi payés par une entreprise pour faire ce travail.



Et ce que le monde du libre peut compter d’ “Amateur” qui font cela pour le plaisir apporte aussi énormément dans la mesure ou leur vision est justement détachée des contraintes de productivité et de planing qui ne sont pas toujours bonnes pour la qualité.


OpenSSL corrige une importante faille qui permettait de récupérer les clés de chiffrement

  • Un problème de réutilisation des clés

  • De nombreuses applications n'utilisent pas la configuration par défaut

  • La version 1.0.2f corrige le problème

Fermer