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)
#1
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.
#2
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.
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.
#3
#4
C’était pas une faille, c’était une feature pour la NSA.
#5
Ha oui, ceci explique cela…
#6
Debian Jessie est restée à la version 1.0.1, ça laisse le temps de voir venir
" />. L’intégration du correctif CVE-2015-3197 ne devrait pas tarder.
#7
Ton message est la preuve qu’une faute est vite commise. Correctement ou correctement ? :)
#8
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.
#9
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.
#10
J’ai pas compris grand chose, mais juste l’essentel : c’est vite corrigé
" />
" />)
(je n’ai pas plus compris les références vers Wikipédia
#11
Surtout quand on prend comme exemple Alice et Bob alors qu’on s’appelle Whitfield et Martin
des vicieux ces mecs !
#12
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.
#13
Si ça n’était pas un troll ça aurait été intéressant d’y répondre.
#14
#15
Si c’est un troll, c’est vachement bon ! Quasi indétectable.
#16
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.
#17
CS est demandé sur la news OpenSSL…
#18
#19
#20
#21
#22
paske tu ne l’es pas encore ????
" />
pff le loser !
#23
#24
#25
“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.”
Option non désactivable. Je ne comprends pas que tout le monde applaudisse.
Ça ce n’est pas de la sécurité.
#26
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é.
#27
Bon, limité à DSA, DHE et OpenSSL 1.0.2, ça limite les dégâts quand même
#28
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.
#29
#30
Je vais me recycler en migration de la couche sécurité en entreprise moi.
#31
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.
#32
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…
#33
non chez adobe, ils connaissent leur failles mais les laisse exprès, c’est différent!
" />
#34
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…
#35
Le libre c’est bon. Mangez en.
" />
#36
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.
#37
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 ».
#38
La règle numéro 3, c’est « ne prends pas n’importe quel prestataire »
#39
#40
Oui, c’est ça, merci.