Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.
OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.
Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).
Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.
Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.
Aller plus loin
- CVE-2014-0160 (772 clics)
- Détail de la vulnérabilité (1173 clics)
- Faille « goto fail » SSL chez Apple en février dernier (289 clics)
- Faille « goto cleanup » chez GnuTLS en mars dernier (248 clics)
# Pour voir si c'est cassé chez vous
Posté par rakoo (site web personnel) . Évalué à 10.
C'est par ici.
[^] # Re: Pour voir si c'est cassé chez vous
Posté par jpph . Évalué à 5.
sympa, le site de ma banque est vulnérable…
[^] # Re: Pour voir si c'est cassé chez vous
Posté par jpph . Évalué à 3.
ah non, ça vient d’être mis a jour …
Réactif finalement ma banque ….
[^] # Re: Pour voir si c'est cassé chez vous
Posté par mansuetus (site web personnel) . Évalué à 4.
Je suis effectivement assez sur le cul de la vitesse de correction par les banques. On peut au moins le reconnaître ça :-)
[^] # Re: Pour voir si c'est cassé chez vous
Posté par ookaze . Évalué à 2.
Pas sûr, il y a des problèmes de charge qui peuvent remonter des faux négatifs.
C'est indiqué sur le site.
[^] # Re: Pour voir si c'est cassé chez vous
Posté par devloop (site web personnel) . Évalué à 1.
http://filippo.io/Heartbleed/#en.wikipedia.org
Le site de Wikipedia semble vulnérable… mais pas toujours. Sans doute une histoire de LoadBalancers.
Il suffit de retenter plusieurs fois.
[^] # Re: Pour voir si c'est cassé chez vous
Posté par mansuetus (site web personnel) . Évalué à 2. Dernière modification le 08 avril 2014 à 11:57.
C'est sérieux ?
J'ai comme l'impression que sa clef secrête est dispo ici :
http://filippo.io/
EDIT : don't panic, chrome a loadé la CSS correctement et ce que je prenais pour une "faille" était un post fort intéressant sur les clefs privées protégées par MDP :-) La question reste : que fait-il des infos collectées ?
[^] # Re: Pour voir si c'est cassé chez vous
Posté par 16aR . Évalué à 2.
C'est une excellente question auquel je laisse les moules les plus paranoïaque répondre.
[^] # Re: Pour voir si c'est cassé chez vous
Posté par Argon . Évalué à 2.
VPS OVH vulnérable sous Debian, mise à jour, c'est bon, merci pour le lien :)
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
# un effet Snowden?
Posté par Albert_ . Évalué à 10.
Je me demande pourquoi les libs de securite se trouvent brutalement audite. Est-ce lie aux relations de Snowden sur la NSA?
[^] # Re: un effet Snowden?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Le chiffrement est de plus en plus utilisé, et logiquement de plus en plus testé (soit par audit, soit directement en prod par les utilisateurs…). D'autant que ce n'est pas figé : nouveaux algos en permanence, découverte de nouvelles classes de failles de sécu, problèmes dans les algos, etc. Et aussi nouvelles méthodes d'audit je présume (généralisation du fuzzing, attaque ciblée sur tel ou tel point).
Une liste partielle tirée des alertes Debian juste sur 2014 et 2013 :
Ou de voir le nombre d'alertes sécu directement à la source chez gnutls ou openssl par exemple.
[^] # Re: un effet Snowden?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Enfin, j'ai toujours eu l'impression qu'il y avait beaucoup de faille sur openssl. Cette bibliothèque revient très régulièrement dans la liste (ce n'est qu'une impression).
[^] # Re: un effet Snowden?
Posté par Raoul Volfoni (site web personnel) . Évalué à 6.
Ce n'est pas qu'une impression. Et c'est aussi une des raisons qui fait que les développeurs d'OpenSSH ont préféré réécrire eux-même le code du parsing d'ASN1 notamment.
Ceci étant le plus gros problème amha reste quand même la façon dont sont traités les problèmes de sécurité avec Openssl (absence de communication avec les distribs ou la communauté par ex.)
[^] # Re: un effet Snowden?
Posté par Ely . Évalué à 10.
J'en profite pour linker un article très intéressant intitulé "What Heartbleed Can Teach The OSS Community About Marketing" : http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/
Ca explique en gros comment le fait d'avoir donné un nom à la fois émotionnel et informatif ainsi qu'un logo au bug a permis une prise de conscience ainsi qu'une réaction immédiate vers la résolution du bug dans le monde entier.
Si le bug avait été "marketé" comme les autres, c'est-à-dire juste par sa fiche "CVE-2014-0160", il n'y aurait jamais eu cet élan de communication.
[^] # Re: un effet Snowden?
Posté par Zenitram (site web personnel) . Évalué à 10.
Plus un outil est utilisé, plus il est interessant d'y trouver une faille et/ou de l'auditer pour trouver des failles.
Ca marche pareil pour tous les outils.
Et la, en plus, la sécurité est devenu (enfin!) quelque chose d'important, tout le monde s'y met car on est tout simplement de plus en plus présent sur le net, et avec nos thunes en ligne.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: un effet Snowden?
Posté par Chuck #1 . Évalué à 1.
TeX me semble moins utilisé qu'OpenSSL, pourtant ça me paraît plus intéressant d'y trouver une faille que dans OpenSSL.
Cette signature est publiée sous licence WTFPL
[^] # Re: un effet Snowden?
Posté par rogo . Évalué à 8.
Je n'ai aucune donnée pour évaluer cette fréquence. Par contre, j'ai lu des critiques acerbes sur la qualité du projet OpenSSL, notamment un échange cinglant sur la liste de développement d'OpenBSD. Grosso modo, ils disaient que si le projet avait été piloté normalement, programmé proprement, et s'il avait respecté un minimum les bonnes pratiques, le bug aurait eu un impact mineur. Selon eux, c'est une accumulations d'erreurs structurelles qui en a fait une faille critique.
Pour se faire une idée du code d'OpenBSD, je recommande la lecture de OpenSSL is written by monkeys (le site a un certificat auto-signé). C'est un compte-rendu des 8 jours qu'un développeur a passé dans le code d'OpenSSL. Les exemples de code qu'il cite au jour 4 sont impressionnants.
[^] # Re: un effet Snowden?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 10 avril 2014 à 15:09.
Difficile du coup de croire au sérieux de la personne sur la sécurité…
Bof.
Il y aura toujours des gens pour dire que l'autre fait de la merde, en attendant si il n'est pas content il peut contribuer ou faire un concurrent qui sera plus mieux bien pour prouver qu'il a raison (ou pas).
En attendant, ben reste qu'on n'a pas mieux en réalité. Trop facile de critiquer comme ça.
[^] # Re: un effet Snowden?
Posté par patate . Évalué à 7.
Qu'on n'aie pas mieux en pratique n'empêche pas forcément qu'il y aie des problèmes dans la manière dont le projet est géré. C'est l'avis de Theo de Raadt, qu'on peut considérer comme sérieux dans le domaine de la sécurité:
http://article.gmane.org/gmane.os.openbsd.misc/211963
Apparemment, OpenSSL a sciemment utilisé un wrapper autour des mallocs et free de la libc pour contourner les vérifications de sécurité qui leurs semblaient trop couteuses en termes de performances sur certaines plateformes…
[^] # Re: un effet Snowden?
Posté par Krunch (site web personnel) . Évalué à 3.
Et l'implémentation custom de malloc/free n'est pas optionnelle (TdR le dit dans le commit log mais ici on a un exemple précis) : http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
Pendant ce temps, l'EFF tente de déterminer à quelle échelle la faille a été exploitée par le passé : https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: un effet Snowden?
Posté par anaseto (site web personnel) . Évalué à 2.
Il semblerait que les développeurs d'OpenBSD ont décidé de faire un nettoyage d'OpenSSL eux-mêmes :
http://undeadly.org/cgi?action=article&sid=20140415093252
ça ressemble à un début de fork :)
[^] # Re: un effet Snowden?
Posté par barmic . Évalué à 7.
GnuTLS est moins bon ? PolarSSL non plus ?
Je présume qu'il doit y en avoir d'autres encore.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: un effet Snowden?
Posté par SaintGermain . Évalué à 0.
Le "if (0)" est de toute beauté ! Je serai curieux de voir si d'autres projets utilisent cette construction (je n'ai pas réussi à faire la requête sur Oloh).
[^] # Re: un effet Snowden?
Posté par Xavier G. . Évalué à 5.
Pour ce qui est de Heartbleed, ci-dessous une explication du programmeur qui a introduit le bug en 2011 en "oubliant de valider une variable".
http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
http://www.20minutes.fr/high-tech/1349037-20140411-heartbleed-erreur-triviale-selon-programmeur-responsable-bug
Il nie toute intervention de la NSA sur celle-ci (en même temps si c'était le cas il ne pourrait le dire publiquement) et sur OpenSSL en général (mais évidemment reconnaît qu'elle a pu être exploitée par l'agence), il assume son "erreur involontaire", et admet que vues les dernières révélations il est logique d'avoir des soupçons, même s'ils sont infondés dans ce cas précis selon lui.
[^] # Re: un effet Snowden?
Posté par Zylabon . Évalué à 3.
Il est citoyen allemand pour ce que j'ai compris… Je ne vois pas ce qui l'interdirait d'en parler.
Please do not feed the trolls
[^] # Re: un effet Snowden?
Posté par ckyl . Évalué à 6.
Porter des chaussettes et des sandales ne protège pas des balles.
Autrement si tu aides une agence gouvernementale à introduire une backdoor dans OpenSSL, je ne suis pas certain que ta nationalité change grand chose si tu décides de le révéler. Je penses que ta vie va bien se compliquer que tu sois citoyen US ou du Kirghizistan. Ca sera peut être un peu plus indirect c'est vrai.
[^] # Re: un effet Snowden?
Posté par khivapia . Évalué à 3.
Pas sûr : le révéler et expliquer publiquement qu'on n'envisage aucunement de se suicider ni de faire des sports dangereux jettera un doute sérieux sur le commanditaire d'un éventuel assassinat… Les services d'espionnage restent toujours dans le déni plausible (en s'abritant par exemple derrière l'incompétence du NIST en matière de sécurité pour la NSA) et refusent de signer leurs forfaits.
[^] # Re: un effet Snowden?
Posté par groumly . Évalué à 4.
Le doute jete lui fera une belle jambe quand il sera le pensionnaire le plus connu du cimetiere…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: un effet Snowden?
Posté par windu.2b . Évalué à 3.
Il reste encore l'accident de la circulation, l'intoxication alimentaire, …
[^] # Re: un effet Snowden?
Posté par benoar . Évalué à 3.
Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat :
https://tools.ietf.org/html/rfc6520
Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
(après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)
[^] # Re: un effet Snowden?
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 1.
Une fois sortie de sa botte l'aiguille parait bien bien poitue, encore faut il la trouver dans la masse de foin…
Quand au code crade, c'est juste pour ne pas dépareiller avec le reste de l'implémentation historique d'openssl.
Il y a une grande différence entre établir une RFC et l'implémenter. OpenSSL est le standard de-facto pour toute nouvelle implémentation, donc souvent la première implémentation est pluôt naive et sert à valider le fonctionnement.
( J'aimerai bien voir du code de schneier… ) On peut être un très bon théoricien et moins porté sur le code.
Il me parait évident qu'avant d'arriver à la communauté ce doit etre revu et corrigé - par de nombreuses personnes -. Le code est là depuis deux ans, personne d'autre que des spécialistes n'en a parlé avant…
Je fais partie des gens qui ont sélectionné openssl avec un pleine confiance en la revue qui était faite et je m'inclus dans le fait qu'on a pas eu l'oeil assez critique sur la masse de changements arrivant avec toutes les nouvelles RFC supportées par 1.0.1.
Avec openssl comme avec tout programme incluant de la sécurité il faut n'ajouter que le stricte nécessaire. On se demande encore qui utilise le heartbeat dans la nature… a part pour en abuser des effets indésirables…
C'est un avertissement, il faut y réagir sereinement et être un peu plus circonspect sur les prochains ajouts.
# FreeBSD
Posté par MTux . Évalué à 6.
FreeBSD 9.2 ne semble pas impacté, OpenSSL est en version 0.9.8y.
[^] # Re: FreeBSD
Posté par linette . Évalué à 1.
Trouvé sur le site on l'on peut faire le test (lien dans le premier commentaire):
"What versions of the OpenSSL are affected?
Status of different versions:
…"
[^] # Re: FreeBSD
Posté par neil . Évalué à 2.
C’est surtout que heartbeat est désactive dans base. FreeBSD 10.0 qui inclut OpenSSL 1.0.1e n’est pas affecté, si on n’utilise pas une autre package.
[^] # Re: FreeBSD
Posté par neil . Évalué à 1.
En fait si, 10.0 est affecté !! http://lists.freebsd.org/pipermail/freebsd-security/2014-April/007405.html
[^] # Re: FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 3.
"We are already working on this but building, reviewing, etc. would take some time"
(et pareil pour Debian Testing pas encore à jour)
Question idiote : ça ne semble pas avoir été fait en full disclosure (Google Securité?), dans ce cas les équipes de sécurité des différentes distros n'ont-elles pas du temps avant divulgation pour préparer le patch et l'appliquer dès la publication de la faille?
(en tous cas, RHEL/CentOS sont plus rapides, déjà patchés depuis plusieurs heures)
[^] # Re: FreeBSD
Posté par neil . Évalué à 5. Dernière modification le 08 avril 2014 à 21:34.
Bah, il faut faire des choix, soit on fait un disclosure responsable, soit on fait un site web avec des jolis logos :-)
Sinon, 10.0-RELEASE-p1 est sorti, pour ceux qui ne voulaient pas appliquer le patch et recompiler base, ni installer openssl depuis les ports (où heartbeat était déjà une option désactivable).
[^] # Re: FreeBSD
Posté par tuxicoman (site web personnel) . Évalué à 4.
testing est à jour:
Réception de : 1 http://ftp.be.debian.org/debian/ jessie/main libssl1.0.0 amd64 1.0.1g-1 [1.008 kB]
Réception de : 2 http://ftp.be.debian.org/debian/ jessie/main openssl amd64 1.0.1g-1 [664 kB]
[^] # Re: FreeBSD
Posté par Frédéric Massot (site web personnel) . Évalué à 4.
À partir de Jessie pensez à installer le paquet "needrestart". Après la mise à jour de libssl1.0.0 il indique les deamons qui utilisent l'ancien version de la lib en mémoire et fourni une interface pour sélectionner ceux que l'on souhaite redémarrer.
[^] # Re: FreeBSD
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Sinon checkrestart dans le paquet debian-goodies ou juste
lsof|grep ssl|grep DEL[^] # Re: FreeBSD
Posté par Kioob (site web personnel) . Évalué à 2.
Très pratique ce paquet «needrestart» merci ! Du coup je l'ai backporté pour mes wheezy.
Je le préfère à l'outil présent dans les debian-goodies, car ça m'évite de déployer curl sur toutes les machines.
alf.life
[^] # Re: FreeBSD
Posté par pasBill pasGates . Évalué à 2.
Cela a ete fait en responsible disclosure.
[^] # Re: FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 09 avril 2014 à 09:12.
Du coup, la question est d'autant plus forte, pourquoi donc ce délai? Le passage dans SID, puis de SID à testing aurait dû être immédiat (et immediat aussi, sans couac, pour Fedora).
Pour RHEL, ça semble avoir été très très rapide (CentOS un peu moins, peut-être pour faire "payer" le fait de ne pas avoir RHEL).
Bref, je n'arrive pas à comprendre le pourquoi de ce délai qui n'est pas acceptable dans le cas du responsible disclosure (c'est tout l'interêt du responsible disclouse d'être protégé dès la connaissance de la faille) et ça fait planner un doute sur la capacité de réaction aux failles de sécurité de la part des distros "communautaires".
Expert des distros Linux, vos explications? les distros communautaires n'ont pas été mises au courant avant la publication de la faille?
[^] # Re: FreeBSD
Posté par ulver . Évalué à 7.
Pour Debian Stable, j'ai eu un mail annonçant la faille avec le paquet fixé le 7 avril à 21H36, ce qui me semble très honnête niveau timing.
J'imagine que dans Sid ça a été tout aussi rapide (à confirmer). Pour testing, cela provient de la manière dont sont gérés les remontées de paquets comme expliqué plus haut. Si tu utilises testing en production, c'est un des risques à prévoir (des MAJ de sécurité un poil plus longues à arriver), et c'est bien expliqué dans la doc.
L'autre distribution communautaire que j'utilise, archlinux (mais pas en serveur), était à jour également le soir du 7 avril : https://www.archlinux.org/packages/core/x86_64/openssl/ : Build Date: 2014-04-07 20:28 UTC
Bref, sur ces deux distribs, aucune raison de se plaindre.
[^] # Re: FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 09 avril 2014 à 10:34.
Merci pour les détails, je n'avais pas suivi la différence de réactivité entre testing et stable.
Et la, du coup, c'est réactif (testing, c'est moins urgent, ce n'est pas en prod), et on voit très bien l'intérêt du responsible disclosure pour les utilisateurs (sinon les utilisateurs savent et… Ne peuvent rien faire).
[^] # Re: FreeBSD
Posté par gouttegd (site web personnel) . Évalué à 10.
L’annonce de la faille a été faite semble-t-il à 17h27 le 7 avril. Si c’est à ce moment-là que le mainteneur de OpenSSL pour Debian en a pris connaissance, je suis d’accord pour dire que publier le paquet corrigé à peine quelques heures plus tard est effectivement « très honnête », voire remarquable.
Mais la question est : est-ce que les développeurs Debian ont été prévenus avant la publication de la faille, ou bien l’ont-ils appris en même temps que le reste du monde ?
À voir le bugtracker de Debian, j’ai bien l’impression qu’ils ont découvert le problème le 7 avril au soir, après l’annonce par openssl.org… donc ils ne sont pas dans le cercle de ceux prévenus à l’avance dans le cadre du « responsible disclosure ».
[^] # Re: FreeBSD
Posté par KiKouN . Évalué à 5.
[^] # Re: FreeBSD
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
Peut-être un manque de confiance au sujet de la discrétion ?
Cela ne signifie pas que ce manque de confiance serait justifié, mais c’est une hypothèse.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: FreeBSD
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Hum, à ce que j’ai compris des commentaires suscité par le billet cité, OpenSSL aurait été prévenu avant, mais justement ils ont attendu qu’OpenSSL soit en mesure de publier le correctif (ce qui aurait révélé la faille) avant d’annoncer la faille. Le responsible disclosure trouve des limites dans le logiciel libre, un développeur de logiciel libre peut être mis confidentiellement au courant, mais celui qui n’installe que des logiciels présents sur un dépôt public ne peut pas installer de correctif à l’avance.
De ce point de vue là, Debian est un peu le perdant de l’affaire… Ils sont obligés d’attendre qu’OpenSSL publie le correctif sur son propre dépôt, ou au moins qu’ils annoncent le correctif en même temps que la faille, donc Debian a nécessairement une longueur de retard.
Et les utilisateurs de Debian qui ne sont pas assez gros doivent attendre que Debian repackage le correctif, donc deux longueurs de retard.
Le fournisseur de service propriétaire peut corriger dans le secret (avec les limites du secret qui permet de ne pas corriger ce qui n’est pas public).
Par contre ce billet où le gars annonce qu’il a pu corriger la faille sur ses services une semaine avant l’annonce de la faille n’honnore pas Yahoo, ils ont été parmi les derniers à mettre en place des corrections alors que vu leur poid, il serait étonnant qu’ils n’aient pas été mis au courant… Ou alors, ça soulève un autre problème majeur, comment un tel poids lourd pourrait être mit à l’écard d’un responsible disclosure.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 9.
Tout est question de savoir si ils ont été prévenu avant. Si tu veux pas trop que des gens sachent de quoi il en retourne exactement (ou alors tu fais signer un NDA à un gars de l'équipe sécu avant de lui filer le patch à tester), tu peux prévenir la veille en disant "attention, que quelqu'un soit prêt à appliquer un patch demain à 17h27".
Quelques heures de retard est encore acceptable, mais vaux mieux 1 heure que 4 heures, et surtout c'est mieux de savoir qu'un patch va arriver (est-ce que ça a été le cas? mystère)
En fait, ça n'honnore personne, c'est super-limite d'avoir priorisé des gens une semaine avant (une semaine, c'est long!), et ça n'honnore surtout pas Cloudfare qui en profite pour se faire de la promo "nous on est dans le secret des dieux".
[^] # Re: FreeBSD
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Pour cloudflare ça me donne une impression de « je voulais m’la pêter mais en fait j’ai gaffé », surtout quand on lit les commentaires qui relèvent le « pourquoi vous et pas moi/lui ? », au final, en voulant vanter son service, le gars a fuité que ça faisait au moins une semaine que la faille était connue et que les initiés se protégeaient…
Jusqu’à ce que je lise cette page, je n’avais aucune notion de temps dans cette affaire, maintenant oui, ce qui peut nourrir la jalousie, le doute, les théories du complot, la susceptibilité, la méfiance, justifier les ressentiments etc. Question communication, il aurait mieux fait de se taire, ou au moins de ne pas dater quoi que ce soit, parce que le temps peut être perçu comme une hiérarchisation.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: FreeBSD
Posté par Anonyme . Évalué à 7.
Apparement il était au depart prevu de rendre la faille publique le 9, ce qui devait laiser 2 jours pour prevenir tous ceux qui devaient l'etre. Mais les developeurs d'OpenSSL on finalement décidé de publier ca immediatement le lundi, peu etre après avoir eu l'impression que trop de monde était deja au courant.
http://www.openwall.com/lists/oss-security/2014/04/08/10
[^] # Re: FreeBSD
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Wow, merci pour le partage, très intéressant, on découvrirait qu’Amazon non plus ne serait pas « dans le secret des dieux ».
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 09 avril 2014 à 16:55.
Merci pour le lien (allez le lire!), où on comprend mieux l'ordre des évenements.
La faute à pas de chance donc si le responsible disclosure n'a pas pu aller jusqu'au bout :(.
(Mais reste de CloudFare prennent tout ce qu'ils peuvent pour se faire de la pub, pour moi c'est une mauvaise pub vu leur façon de se la péter mais je suis sûr que plein de monde va trouver ça bien)
[^] # Re: FreeBSD
Posté par claudex . Évalué à 10.
C'est assez intéressant à lire. Red Hat a été au courant la première 1 et a prévenu dans le quart d'heure les autres distributions (et ces distributions la remercie au passage). Il était donc prévu d'attendre deux jours mais il semblerait que la découverte par deux équipes différentes de la faille ait fait penser que c'était trop connu et la faille a été rendue publique par OpenSSL.
Un employé de Red Hat bossant pour OpenSSL était au courant plus tôt mais n'a pas prévenu son employeur tout de suite pour ne pas le privilégier, on peut quand même apprécier la transparence de RH. ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: FreeBSD
Posté par jyes . Évalué à 2.
C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).
Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.
En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).
[0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.
[^] # Re: FreeBSD
Posté par ulver . Évalué à 2.
Je n'ai peut être pas bien compris ce que tu voulais dire, mais en tout cas, si, Debian Stable (wheezy) a bien été impacté par ce bug OpenSSL. Oldstable (Squeeze) non par contre, car la version d'OpenSSL était plus ancienne.
[^] # Re: FreeBSD
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Oui, par contre wheezy a reçu un correctif tout de suite, alors qu’en effet, pour jessie ça a tardé, mais celui qui met jessie en prod sait à quoi s’attendre…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: FreeBSD
Posté par jyes . Évalué à 4.
Oui, mille excuses pour la désinformation. Erreur de ma part. La machine sur laquelle j’ai fait la vérification était en « oldstable » et non « stable ».
# Une analyse du bug.
Posté par Burps . Évalué à 3. Dernière modification le 08 avril 2014 à 13:59.
Pour les flemmards comme moi qui ne sont pas allés voir le patch:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Ça semble (un peu) moins critique que le laisse entendre la description initiale: on ne peut pas lire 64k où l'on veut. Donc récupérer le certificat doit fortement dépendre de la disposition de la mémoire…
[^] # Re: Une analyse du bug.
Posté par knarf2 . Évalué à 9.
Dans le dump que j'obtient de certains serveur vulnérable j'ai des entêtes de requête HTTP avec notamment les cookies de session, en les utilisant j'ai réussi à utiliser le compte d'une personne random… C'est quand même assez critique.
[^] # Re: Une analyse du bug.
Posté par ulver . Évalué à 10. Dernière modification le 08 avril 2014 à 18:25.
En exploitant la faille sur login.yahoo.com (qui est toujours vulnérable à cette heure-ci, quelle honte), une fois sur deux, tu as un login/password qui tombe.
Donc pas critique… si, un peu quand même ;)
[^] # Re: Une analyse du bug.
Posté par rewind (Mastodon) . Évalué à 2.
Et le patch est là
[^] # Re: Une analyse du bug.
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est vrai que la dépèche est un peu trop "ça le fait à tous les coups".
"autorisant" --> "autorisant potentiellement (suivant le contenu du bloc aléatoirement accédé)"?
[^] # Re: Une analyse du bug.
Posté par pasBill pasGates . Évalué à 10.
Non non, autorisant.
T'es libre d'envoyer autant de requetes que tu veux hein… et t'es aussi libre d'envoyer d'autres requetes au systeme afin d'exercer l'allocateur et lui faire mettre en memoire ce que tu veux lire.
Il n'y a pas de 'potentiel', c'est avere, ca prend simplement plus qu'une requete pour avoir ce que tu veux.
[^] # Re: Une analyse du bug.
Posté par claudex . Évalué à 10.
Chez moi, les barrettes de ram sont à côté du CPU.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une analyse du bug.
Posté par Burps . Évalué à 0.
Avec un MMU entre les deux…
[^] # Re: Une analyse du bug.
Posté par tatrefthekiller . Évalué à -2.
Je pense qu'il voulait dire : dépendre de la disposition des données dans la mémoire.
[^] # Re: Une analyse du bug.
Posté par Burps . Évalué à 10.
Nonon. Je parlais bien de la disposition des barrettes. Par exemple, en mode réel, si elles sont en cercle de 256k de rayon, et que tu lis 64k vers le centre, tu tombes sur du vide.
[^] # Re: Une analyse du bug.
Posté par maboiteaspam . Évalué à 4.
L'analyse est intéressante à lire. Mais cela me rappelle trop une certaine époque en php où il n'était cesser de râbâcher que les entrées utilisateurs c'est le mal absolu et qu'il fallait s'en méfier comme de bill gates.
Mais le fait est que s'appuyer sur la compétence des hommes, même les meilleurs de chez openssl, ne peux suffire pour se mettre à l'abri.
Du coup, comme suggéré en fin d'article, changer de langage reste la seule option décemment concevable.
A t'on réellement besoin de le faire en C ?
La rapidité d'exécution est elle si nécessaire pour ce point particulier ?
Je veux dire que la crypto par la nature même de la solution qu'elle apporte est très lente à exécuter sur un ordinateur.
Ne peut on pas dès lors se permettre un peu plus de lenteur au prix d'une sécurité véritablement accrue ?
Dit autrement, a quand une implémentation d'openssl en rust ?
Bon par contre, pour un genre de raison similaire à ce cve, Java n'est pas une alternative envisageable :D /désolé/
[^] # Re: Une analyse du bug.
Posté par Anthony Jaguenaud . Évalué à 3.
Si seulement un langage sans possibilité de faille existait… il y a longtemps qu'il serait utilisé.
[^] # Re: Une analyse du bug.
Posté par anaseto (site web personnel) . Évalué à 8.
Pas forcément, tu as bien coq et d'autres systèmes de preuves formels dont tu peux extraire des programmes certifiés. Il y a aussi des outils pour prouver formellement des propriétés sur du code C, ou d'autres langages. Si c'est pas très utilisé (à part pour certains systèmes critiques) c'est surtout parce que ça demande beaucoup plus de travail, et que peut-être pour beaucoup même trop pour juste une grosse faille toutes les plusieurs années.
Sinon, c'est quand même vrai que les dépassement de mémoire c'est beaucoup plus courant avec du code C qu'avec d'autres langages où tu ne gères pas la mémoire et tu dois juste faire confiance au GC, dont les bugs sont moins courants normalement, du moins il me semble.
[^] # Re: Une analyse du bug.
Posté par Burps . Évalué à 1.
C'est un mieux, mais ça ne doit pas donner un sentiment de sécurité à toute épreuve.
Une analyse en Coq ne va donner qu'une correction fonctionnelle ou, si tu as été jusqu'à formaliser un modèle crypto, ne va donner qu'une preuve de sécurité pour le modèle d'adversaire que tu captures.
De même, l'utilisation d'un GC va introduire des canaux cachés difficilement contrôlables.
[^] # Re: Une analyse du bug.
Posté par ckyl . Évalué à 2.
Tiens puisque le monsieur à eu un peu d'exposition ces dernières semaines:
http://channel9.msdn.com/Events/Build/2014/3-642
http://research.microsoft.com/en-us/um/people/lamport/pubs/state-machine.pdf (preface)
http://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/
[^] # Re: Une analyse du bug.
Posté par reno . Évalué à 8.
Tu rêve: si la sécurité était vraiment prise au sérieux, le C ne serait pas utilisé sur ce genre de projet: Ada ça existe déjà depuis longtemps..
Certes, Ada n’empêche pas de faire des erreurs de durée de vie des variable comme Rust, mais il a le mérite d'être mature et d'exister depuis longtemps et de résoudre 99% des problèmes du C ce qui
est déjà un net progrès!
[^] # Re: Une analyse du bug.
Posté par pasBill pasGates . Évalué à 3.
Ada ? Pfffff….
http://www.mitls.org/wsgi
Oh, et c'est partenariat de MS Research et l'INRIA
[^] # Re: Une analyse du bug.
Posté par claudex . Évalué à 5.
Et c'est en F# pour ceux qui ne veulent pas cliquer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une analyse du bug.
Posté par reno . Évalué à -3.
Note que F# a un sacré handicap: Microsoft! Pas besoin de détailler je pense..
[^] # Re: Une analyse du bug.
Posté par Burps . Évalué à 4.
C'est une implémentation de référence, pas une implémentation destinée à être utilisée en production. C'est pour montrer l'utilité des méthodes formelles, et leur application à des protocoles conséquents. C'est transposable à d'autres langages (et comme je l'ai dit plus, ce n'est pas à toute épreuve, le GC introduisant des canaux cachés par exemple).
Aussi, l'implémentation de F# est sous Apache2 et testée sous Mono. C'est donc testable librement… même si encore une fois, je comprends qu'on ne puisse/veuille pas mettre un runtime mono où l'on veut !
[^] # Re: Une analyse du bug.
Posté par Albert_ . Évalué à -3. Dernière modification le 10 avril 2014 à 17:39.
c'est surtout pas multi-OS donc ca sert a rien dans le cas present.
[^] # Re: Une analyse du bug.
Posté par patate . Évalué à 7.
F# tourne sous Windows, Linux, MacOSX, iOS, Android et est open-source. A priori ca devrait entrer dans la catégorie multi-OS.
[^] # Re: Une analyse du bug.
Posté par zul (site web personnel) . Évalué à 3.
C'est bien de mettre en exergue la qualité des labos français pour une fois :D
[^] # Re: Une analyse du bug.
Posté par pasBill pasGates . Évalué à 10.
Les francais ont toujours ete bon de ce cote la, le probleme francais c'est de tourner ca en une industrie malheureusement.
[^] # Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 3.
Quand Rust sera prêt, peut-être… :-p
Plus sérieusement, c'est un peu naïf de dire qu'OpenSSL est écrit en C. Parce que quand tu fais de la crypto tu dois faire de l'assembleur, et du coup reposer sur un langage plus évolué que C pour tester tes accès mémoire est une vaste blague, puisque ça ne concerne pas tout ton code.
Dit autrement, explique-moi comment tu ré-écris ça en Rust ou comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-x86_64.pl
Et comme aujourd'hui il y a des nouvelles opérations dédiées à la crypto directement dans le processeurs et qu'elles changent à chaque nouvelle version des processeurs, l'assembleur a de beaux jours devant lui.
Après t'as des gens qui ont fait une lib ssl complète en Ada, t'en auras qui le feront en Rust un jour (en plus c'est cool), mais à côté des opcodes AES (ou même juste vectoriels) dans les processeurs, j'ai peur que le rapport de performance reste de 100 ou 1000…
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 1.
Et encore j'ai pas linké la bonne implem, celle qui n'est vraiment pas possible d'écrire en Rust:
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par programLyrique . Évalué à 6.
Non, c'est juste pour avoir de meilleures performances que c'est fait en assembleur.
On peut très bien implémenter AES en C, en Java, ou en OCaml. Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.
Par ailleurs, on peut mettre de l'assembleur inline dans du code Rust (dans un bloc unsafe) :
Rust release notes
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 3.
Pour faire de la crypto en labo non, mais pour faire le site de vente en ligne ou d'une banque, je crains que si.
Exactement. Juste, c'est le mot.
Et l'assembleur mis en inline dedans, Rust s'assure qu'il n'y a pas de buffer overflow dedans ?
;-)
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Thomas Douillard . Évalué à 4.
Ça isole un peu la partie du code à vérifier si on sait déja qu'il n'y a que là qu'il y a des risques d'en avoir.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par lasher . Évalué à 5.
Oui alors euh, certains des gens qui faisaient de la crypto dans mon labo avaient des petites phrases du genre « C est trop haut-niveau, c'est chiant, quand j'ai un overflow (que je pourrais exploiter) il me le dit pas ! ».
Sinon, si pas mal de mes collègues cryptologues avaient effectivement commencé à bosser sur des softs de type
magmapour représenter leurs courbes elliptiques etc., une fois que leurs protocoles étaient au point et testés, ils ont quand même eu à aller recoder leurs algos en C aveclibgmp(à l'époque je crois que c'est ce qu'ils utilisaient). Sinon, il aurait été difficile de déterminer en combien de temps leurs attaques allaient réellement porter leurs fruits, etc. Et oui, au bout d'un moment, il y avait aussi du SSE voire du AVX qui entrait dans la danse…[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Burps . Évalué à 2.
Et pour éviter de se faire casser son chiffrement de disque dur en 1s.
http://www.cs.tau.ac.il/~tromer/papers/cache.pdf
PS: je suis un grand utilisateur de langages de haut niveau. Mais il reste du travail à faire pour avoir des implémentations efficaces et sûres des primitives cryptographiques.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par programLyrique . Évalué à 2.
Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.
Dans les contremesures, ils parlent aussi d'autres solutions qu'utiliser l'extension Intel pour activer un no-fill mode, ou l'implémentation bitslice.
Il y a quelques contre mesures qui ne nécessitent pas de coder en assembleur, à première vue : section 5.2, alternative lookup tables, 5.3 (pour le dernier paragraphe), 5.4, these countermeasures […] are algorithmic en rajoutant des transformations aléatoires etc…
Bref, comme les auteurs le rappellent, les méthodes qui n'utilisent pas l'assembleur sont :
Encore une question de performance, non ?
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Burps . Évalué à 5.
Je ne trouve pas l'hypothèse si forte: tu peux retrouver la clé de chiffrement d'un disque dur pour une machine sur laquelle tu as un simple accès car dans ce cas tu peux forcer le programme de chiffrement à fonctionner en écrivant sur le disque dur. Ça a été fait en pratique, et c'est très efficace—bien sûr, ça ne marche plus aujourd'hui.
J'avais été voir une présentation de Shamir au collège de France. Il y avait présenté une attaque basée sur les variations de la tension sur les ports USB ou du bruit émis par la machine: le stepping du processeur, qui change suivant la charge demandée, provoque ces variations, au point que statistiquement tu arrives à différencier les multiplications des additions (et donc le bit de poids faible en cours d'inspection) lors du chiffrement RSA. A l'époque, c'était encore un peu fumeux, mais l'attaque s'améliore:
https://eprint.iacr.org/2013/857
Par rapport à mon propos, oui et non. Oui, l'instruction Intel est là pour protéger AES contre ces attaques sans avoir une dégradation catastrophique des performances. Mais non, quitter l'assembleur ne va pas régler le problème des canaux cachés. J'aurais tendance à dire: au contraire même. Et l'analyse de ces implémentations va, avec l'état de l'art courant, être bien difficile aussi: il n'y a pas de modèle du JIT, il n'y a pas de modèle du GC. Ça ne veut pas dire que ça ne va pas arriver… et dans ce cas, avoir un langage de haut niveau permettra de mieux analyser le protocole en lui-même. Car TLS (même en 1.2) est très limite niveau crypto, et la RFC laisse certaine partie à interprétation.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Kerro . Évalué à 6.
C'est potentiellement le cas de tous les serveurs web des hébergeurs par exemple.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Zenitram (site web personnel) . Évalué à -3.
C'est sûr qu'en disant ce dont ont besoin les autres à leur place, c'est facile.
Maintenant, je suis heureux de lire que quand j'achète un CPU, tu n'en offres 99 du même type (et la machine autour, et le prix de location de la baie…)
OK, ton offre n'est pas crédible, donc il reste juste à dire : foutaises, ça c'est le discours d'une personne qui a quelques utilisateurs sur sa machine et qui pense que tout le monde est comme lui, mais ce n'est pas le cas.
Qui va être aussi rapide que l'ASM avec AES-NI, oui ou non?
"pouvoir" n'est pas suffisant, je peux traverse l'atlantique en voilier mais pas foule va faire pareil et va préférer l'avion, normal.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par programLyrique . Évalué à 3.
Je ne suis pas sûr de comprendre ta remarque… je me contentais de faire une remarque théorique, et aucunement de proposer à tout le monde d'utiliser une implémentation prouvée et générée à partir de Coq d'AES.
Oui, on peut effectivement implémenter AES avec C, Java ou Ocaml, et oui, ce sera effectivement moins rapide qu'en ASM.
Une comparaison plus adéquate aurait été entre descendre de la tour Effel en sautant en parachute (risqué) ou par les escaliers (moins risqué mais plus lent) - et il y a un compromis… les ascenseurs- .
Ainsi, si utiliser un langage de plus haut niveau avec des garantis statiques fortes apportait plus de confiance dans l'implémentation, personnellement, je préfèrerais utiliser utiliser cette implémentation qu'une implémentation très rapide ; peu m'importe que me loguer sur le site de ma banque prenne du temps, mais qu'on puisse faire des virements bancaires à partir de mon compte à mon insu, par contre, ça me gênerait…
Cependant, Burps indique de façon convaincante que ce n'est pas que pour des raisons de performance qu'on utilise l'assembleur, mais aussi pour éviter des attaques, donc ça parait bien plus justifié d'utiliser l'assembleur.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 10 avril 2014 à 13:18.
Oui, bon, en gros tu dis que tu veux un truc sûr même si il ne répond plus au besoin initial. Facile!
Tu viens de montrer que tu n'as absolument rien compris au problème.
Si toi tu es prêt à payer plus cher, d'autres ne le sont pas. (je n'ai pas parlé de latence, j'ai parlé de cout dans mon message…)
Oui, on parle d'argent (du cout d'un CPU, d'une baie, de la maintenance…), tu es complètement hors sujet avec ta question de temps et montre que tu ne comprends pas le besoin et en quoi AES-NI répond plus au besoin que ton language haut niveau "sécurisant".
Comme tu dis, c'est une question de compromis, et le compromis choisis par la majorité des gens n'est pas le tiens, ça n'empèche toutefoirs personne de te proposer (plus cher) ce que tu veux… Si il y a une réelle demande.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par programLyrique . Évalué à 4.
Détrompe-toi :
Si d'autres sont prêts à payer moins cher quitte à avoir une moins bonne sécurité, d'autres ne le sont pas.
Ha bon ? Celui de privilégier la sécurité ? Tu as des chiffres ?
J'ai comme l'impression que tu n'as pas vraiment compris ma remarque et que tu n'as pas lu ma dernière phrase :
A partir du moment où l'assembleur permet d'obtenir une meilleure sécurité, c'est un bon choix. Si en plus, il permet d'avoir de meilleures performances et de réduire les coûts, c'est encore mieux.
Il n'est pas sûr en plus qu'utiliser une implémentation avec des failles de sécurité permettent de réduire les coûts in fine, s'il faut rembourser des utilisateurs floués, mettre à jour les programmes et l'infrastructure, restaurer des sauvegardes, voir l'image de l'organisation complètement détruite devant les utilisateurs.
Avant d'affirmer de façon péremptoire que ça va coûter plus cher ou moins cher (tu as peut-être raison), moi, je préfère étudier la question plus en détails.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 7.
D'ailleurs, je propose une solution sans Rust, sans Ada, sans Go et sans C¹:
Il suffit de débrancher l'électricité, de prendre une² feuille de papier et du crayon et de faire à la main, c'est possible et c'est juste moins performant. :-)
¹: je n'ai pas dit "sensé", j'ai dis "sans C"
²: ok, il va falloir plusieurs feuilles, et probablement une gomme également, mais ça reste juste une question de performance par rapport aux opcodes aesni
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par ariasuni . Évalué à 1.
Mais la plus grosse faille (et source d'erreurs) reste l'interface chaise-clavier.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 1.
Ah bah surtout une fois qu'on a éteint l'électricité et qu'on encode l'AES et le RSA à la main, ça, va y avoir de l'erreur humaine à gogo. :-)
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par khivapia . Évalué à 2.
quand j'achète un CPU, tu n'en offres 99 du même type
J'offre une implémentation bitslice qui permet de traiter le chiffrement 64 fois plus vite pour 64 clients en parallèle, ce qui est certainement plus efficace pour l'AES que les implémentations standard (l'AES n'a pas été inventé pour être spéclamement efficace pour les plate-formes logicielles 64 bits).
Qui va être aussi rapide que l'ASM avec AES-NI, oui ou non?
Sans aucun doute avec les intrinsics C/C++ de gcc, qui devraient être présentes dans les autres langages et permettent de faire de l'assembleur avec la rigueur d'un appel de fonction bien connue par le compilateur.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par khivapia . Évalué à 2.
comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
Faire appel aux fonctions intrinsics ?
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 1. Dernière modification le 10 avril 2014 à 12:05.
Je ne comprends pas bien ce que les les fonctions intrinsics de Rust apportent pour soit implémenter de la crypto avec les opcodes AESNI en Rust soit garantir que du code assembleur ajouté à un programme Rust ne contienne pas de buffer underrun.
Mais je veux bien comprendre.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par reno . Évalué à 3.
Je pense qu'une façon de faire serait de modéliser le comportement des fonctions utilisées et valider le fait que le code assembleur ne contient pas de buffer overflow.
Ça ne marcherai pas avec tout les programmes assembleur, mais bon ça devrait marcher avec un nombre suffisant..
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 0.
Ton modélisateur, dès qu'il sera au point, te vaudra le prix Nobel.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par reno . Évalué à 3.
Faux,
1) il n'y a pas besoin de modéliser tout l'assembleur pour que ça soit utile dans le cas dont on parle
2) ça existe déjà je pense:
http://www.reddit.com/r/ReverseEngineering/comments/1jz3qv/formal_specification_of_the_x86_instruction_set/
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par khivapia . Évalué à 2.
Je voulais dire qu'il y aura certainement en Rust des fonctions intrinsics qui permettent d'appeler directement les opérations assembleur d'un chiffrement AES, comme il y en a déjà en C/C++ avec gcc et d'autres compilateurs. Sinon ce serait une grosse limitation de Rust.
L'intérêt de ces fonctions est de pouvoir faire de l'assembleur avec la rigueur sémantique d'une fonction du langage.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 1. Dernière modification le 10 avril 2014 à 21:23.
Eh bien figure-toi qu'il n'y en a pas non plus en C/C++ (et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique), c'est pour ça que quand on doit utiliser ce genre d'opcodes on le fait en assembleur.
Ce n'est pas parce que Rust, comme d'autres langages, donne accès aux opérations atomiques qu'il donnera accès à toutes les opérations des processeurs.
Pour illustrer, on peut prendre une opération beaucoup moins spécialisée: la rotation de bit, qui est un équivalent du décallage de bit (opérateurs << et >> en C, Java & co) mais où le bit qui disapraît à droite ou à gauche réapparait de l'autre côté. Ces opérations existent depuis plus de 30 ans dans tous les processeurs (à part peut-être certains RISC j'en sais rien), et il n'y a pas de méthode ou d'opérateur standard en C pour effectuer cette opération. Probablement parce qu'il est rare d'en avoir besoin à part dans des algos ultra optimisés. Et ça fait plus de 30 ans.
Et la rotation de bit, elle existe sur tous les processeurs, contrairement aux spécificités comme AESNI. Donc ce serait facile de fournir un langage fortement portable avec des rotations de bits. Pour AESNI en revanche…
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par khivapia . Évalué à 7. Dernière modification le 11 avril 2014 à 10:25.
Pardon ? Chez moi j'ai un joli fichier wmmintrin.h fourni par GCC, qui contient les fonctions C à appeler sur des données C, que le compilateur remplace par l'instruction AES-NI si elle est présente.
Idem avec la quasitotalité des fonctions vectorielles.
Ce n'est pas comme s'il était impossible de générer des codes path différents à l'exécution si jamais l'instruction n'était pas présente sur le CPU.
La rotation de bits s'écrit en une macro C ou une fonction template C++ avec 2 shift et un OR, et ce n'est pas comme si les compilateurs ne détectaient pas le pattern depuis au moins 10 ans pour le remplacer par l'instruction spécifique si besoin.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 2.
Au temps pour moi, je suis confus, quand j'ai regardé les intrinsics gcc j'ai eu la bêtise de le faire sur une machine où il y avait un vieux gcc (4.1.2).
Cela dit je serai curieux de savoir pourquoi ni openssl ni gnutls ne les utilisent (les deux libs font directement de l'assembleur).
Ou (corollaire) qui utilise ces intrinsics, puisque les deux principaux utilisateurs libres potentiels qui me viennent à l'esprit ne les utilisent pas…
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par maboiteaspam . Évalué à 0. Dernière modification le 10 avril 2014 à 13:42.
c'était totalement naïf comme post.
J'ai cité rust, comme j'aurais pu/du citer Ada, ou d'autres.
Qu'importe ! ai je envie de dire.
L'idée étant celle-ci, à jouer avec le feu, tu finis invariablement par te faire brûler (un matheux passant par là pourrait pbblmt nous le théoriser).
Dès lors ne peut on pas, juste, éviter de jouer avec le feu.
C'est la gestion du risque dans toute sa splendeur. Partant du principe que cela n'arrivera que 0.0001% des cas, alors c'est acceptable de jouer avec le feu.
Malheureusement, sans vouloir faire des comparaisons dé raisonnés, les centrales nucléaires sont conçus avec un risque de 0.000000001% et pourtant déjà elles ont explosé plusieurs fois.
Le problème de la finance actuel est du même acabit.
Sinon, non aucune foutre idée de comment ré implémenter cela en rust, je fuis le C comme bill gates.
Par contre j'aimerais bien avoir du temps pour apprendre rust et voir si c'est aussi bien fichu que nodejs, outre le langage itself.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 4.
C'est bien à ça que je réponds: tu dis que le problème vient de l'utilisation du C, mais tu ne connais pas le sujet et n'a pas envie de le connaître, sauf que justement on est en plein cœur d'une des rares utilisation actuelles ou le C et l'assembleur restent incontournables. Malgré leurs défauts (et là on s'en tape un en pleine face, c'est clair).
La crypto doit être à la fois optimisée en perfs, facile à auditer (plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites) et disponible sur toutes les plateformes (Rust c'est 4 plateformes pour le moment, Ada je ne dis pas). C'est contraignant comme du réseau ou du noyau.
Sachant qu'en l'occurrence le bug n'était pas un problème de lecture dans un pointeur mal alloué qui se règlerait trivialement avec un array de plus haut niveau qui ferait lui-même le bound-check comme en Rust, en C++, en Pascal ou en Visual Basic. C'était l'oubli d'un sanity check sur la valeur lue dans le message réseau qui arrive, auquel le code a malheureusement¹ fait confiance aveuglément.
C'est bien expliqué dans le lien plus haut, en même temps c'est tellement simple que ça se voit bien dans le correctif aussi (d'autant plus qu'il a été largement commenté ligne à ligne, probablement un effet médiatique ;-)):
https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead
¹: exprès, disent les plus méfiants
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par maboiteaspam . Évalué à 2.
Oui.
En fait, à y réfléchir deux fois, le titre m'a trompé, car corriges moi si je me trompes, le bug survient dans la lib ssl certes, mais c'est d'abord et avant tout un problème de lecture des request/response.
Donc plus un problème de nature réseau que crypto. (ahaalal … )
Au moins tout cela était intéressant à lire !
Je ne perçois pas bien ce que cela signifie concrètement.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . Évalué à 0.
Je veux dire que c'est plus simple d'auditer un switch case tout moche qu'un ensemble de méthodes surchargées (polymorphisme dynamique) qui prennent des lambda en paramètre.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par xcomcmdr . Évalué à 6.
Il y a un juste milieu entre du code indigeste et du code obfusqué, quand même…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Thomas Douillard . Évalué à 6.
Le comportement déclaratif il porte en général une sémantique qui fait que le compilateur doit nécessairement garantir des tas de propriétés qu'il font que c'est plus simple de vérifier, voire de prouver qu'il est exempt d'une certains classe de bugs. Pour l'implicite, je vois pas trop le rapport avec la hauteur du langage, les cast implicites il y en a en C et c'est pas toujours beau à voir.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par Parleur . Évalué à 6.
Haha.
https://www.youtube.com/watch?v=a7dxnTNOwZE
[^] # Re: Une analyse du bug.
Posté par pudbou . Évalué à 5.
Un autre intérêt du C, c'est que de par sa rusticité, ça se compile sur un tas d'architectures différentes. Et quand tu veux porter openssl sur une nouvelle architecture ça me paraît plus simple d'adapter le programme en C que de porter le compilateur + runtime de Rust/Ada/etc.
# Debian Jessie
Posté par Matthieu . Évalué à 2.
Les informations chez Debian sont incohérentes :
D'un côté :
http://www.debian.org/security/2014/dsa-2896.en.html
For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.
De l'autre :
https://security-tracker.debian.org/tracker/CVE-2014-0160
jessie 1.0.1f-1 vulnerable
Au final, l'apt-get update/upgrade ne propose pas la version 1.0.1g
Pour moi, Jessie est toujours vulnérable, alors que les autres versions debian ne le sont pas ou plus.
[^] # Re: Debian Jessie
Posté par zebra3 . Évalué à 10.
J'espère que juste que ce n'est pas une correction à la debian :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Debian Jessie
Posté par Matthieu . Évalué à 3.
Bon, pour les impatients comme moi, vous pouvez repackager openssl pour jessie en le compilant avec l'option -DOPENSSL_NO_HEARTBEATS
bash$ apt-get source openssl
bash$ cd openssl-1.0.1f
bash$ vi Configure
j'ai rajouté ligne 1519 après :
cflags.=" -DOPENSSL_BN_ASM_GF2m" if ($bn_obj =~ /-gf2m/);
la ligne :
$cflags.=" -DOPENSSL_NO_HEARTBEATS";
ensuite :
bash$ dpkg-buildpackage -b -D
rajoutez -j(nombre de coeur) pour aller plus vite
bash$ cd …
Vous trouverez 2 package .deb créés :
bash$ dpkg -i openssl_1.0.1f-1_amd64.deb libssl1.0.0_1.0.1f-1_amd64.deb
Redémarrez votre service apache.
En utilisant cet outil python http://s3.jspenguin.org/ssltest.py vous pourrez valider que votre serveur n'est plus vulnérable.
No heartbeat response received, server likely not vulnerable
[^] # Re: Debian Jessie
Posté par mansuetus (site web personnel) . Évalué à 2.
Miroir: http://pastebin.com/WmxzjkXJ
[^] # Re: Debian Jessie
Posté par Thomas Debesse (site web personnel) . Évalué à -1. Dernière modification le 09 avril 2014 à 06:36.
Méfiance, hier chez Debian ils disaient que la 1.0.1e-2+deb7u5 était corrigée, mais il semble que non.
Hier sur https://security-tracker.debian.org/tracker/CVE-2014-0160 on lisait :
hors pourtant :
Alors qu’on devrait obtenir quelque chose comme :
Aujourd’hui sur https://security-tracker.debian.org/tracker/CVE-2014-0160 on lit :
Une version 1.0.1e-2+deb7u6 serait sortie, mais là-encore…
Qui croire ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Debian Jessie
Posté par ThibG (site web personnel) . Évalué à 4.
A priori le bug est bien corrigé par 1.0.1e-2+deb7u5, 1.0.1e-2+deb7u6 rajoute un test au moment de la mise à jour pour détecter quels services sont vulnérables (et les relancer, histoire que tu n'aies pas à le faire manuellement).
Question bête : tu as bien mis à jour libssl1.0.0 ?
[^] # Re: Debian Jessie
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Ouch, merci, c’était très bête…
En installant libssl1.0.0=1.0.1e-2+deb7u6, automatiquement dkg-reconfigure me propose de redémarrer :
Et sans même rebooter :
Hum, il aurait été plus prudent que Debian déclare le paquet openssl comme dépendant du paquet libssl avec une dépendance
=ou>=à la version du paquet d’openssl.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Debian Jessie
Posté par Kioob (site web personnel) . Évalué à 2.
Attention, le paquet ne détecte pas tous les cas. Par exemple stud, mysql/mariadb et pure-ftpd ne sont pas détectés comme services à relancer, à tort.
alf.life
[^] # Re: Debian Jessie
Posté par duf . Évalué à 1.
perso quand j'ai fait la MAJ j'avais que le patch u5 du coup mon apache n'a pas été redémarré, je m'en suis rendu compte en testant le soir….
mais du coup ça a été réactif avec le u6 pour ceux qui n'auraient pas pensé à relancer ou tester leurs services.
[^] # Re: Debian Jessie
Posté par Seb (site web personnel) . Évalué à 3.
Un outil bien pratique pour tester les process qui tournent sur d'anciennes libs après une mise à jour, c'est
checkrestart:# apt-get install debian-goodies# checkrestartTant qu'il le peut il listera les services concernés, sinon il est parfois utile de le lancer avec
-vpour obtenir plus de détails.[^] # Re: Debian Jessie
Posté par GnunuX (site web personnel) . Évalué à 3.
Hum, ce script ne fonctionne pas quand on a des conteneurs ….
Peu pratique.
[^] # Re: Debian Jessie
Posté par KiKouN . Évalué à 2.
A noter qu'un reload semble suffir pour apache.
[^] # Re: Debian Jessie
Posté par gouttegd (site web personnel) . Évalué à 8.
Un reload suffit peut-être pour qu’Apache utilise la version mise à jour de la bibliothèque, mais ça ne corrigera pas le fait que les clefs privées des certificats SSL ont peut être déjà fuité…
Donc non, on ne peut pas simplement mettre à jour libssl, recharger les serveurs et se croire tranquille. Il faut aussi renouveller les certificats.
[^] # Re: Debian Jessie
Posté par Laurent Cligny (site web personnel) . Évalué à 5.
Je préciserais, recréer les clés privées puis renouveler les certificats.
[^] # Re: Debian Jessie
Posté par gouttegd (site web personnel) . Évalué à 5.
Tout-à-fait. Et révoquer les anciens certificats, aussi, qui pourraient sinon être ré-utilisés par les bad guys pour se faire passer pour quelqu’un d’autre.
[^] # Re: Debian Jessie
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
Absolument. Merci de préciser ma précision ;)
[^] # Re: Debian Jessie
Posté par ulver . Évalué à 4.
Ton serveur apache doit encore utiliser les anciennes libs.
Tente un "lsof -n | grep ssl | grep DEL".
Si tu vois des trucs, il faut que tu redémarres apache (et tout autre process que tu verrais dans le lot). Ceci dit, Debian a sorti en fin de journée un autre patch qui se charge de redémarrer tous les services nécessaires (le u6 que tu vois sûrement), mais j'ai pas testé.
[^] # Re: Debian Jessie
Posté par MTux . Évalué à 1.
D'oh !!!!
Bon désolé c'était facile.
Pour revenir aux choses sérieuses, il fut un temps où j'utilisais debian testing, et je me suis toujours demandé comment étaient gérées les failles de sécurité de ce type. Vu que c'est du testing est-ce sécurisé à 100 % ? Pas sûr…
[^] # Re: Debian Jessie
Posté par Guy . Évalué à 3.
C'est un défaut (ou une qualité?) de testing (jessie): tout ses paquets proviennent de sid, y compris les corrections de sécurité. Il faudra donc un passage des paquets ssl dans sid (plus ou moins long, cela dépend de la température du fut du canon) avant de les voir débarquer dans jessie…
[^] # Re: Debian Jessie
Posté par Adrien . Évalué à 4.
D'après la FAQ :
La sécurité pour testing bénéficie des efforts sur la sécurité réalisés par tout le projet pour unstable. Cependant, un délai minimal de deux jours existe pour la migration, et les correctifs de sécurité peuvent parfois être retenus par les transitions. L’équipe chargée de la sécurité aide à faire avancer ces transitions qui retiennent les envois de sécurité importants, mais ce n’est pas toujours possible et des contretemps peuvent survenir. En particulier, les mois qui suivent une nouvelle publication de stable, quand de nombreuses nouvelles versions sont envoyées dans unstable, les correctifs de sécurité pourraient être mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable.
http://www.debian.org/security/faq#testing
[^] # Re: Debian Jessie
Posté par tuxicoman (site web personnel) . Évalué à 1.
Ca vient d'arriver sur le miroir
Réception de : 1 http://ftp.be.debian.org/debian/ jessie/main libssl1.0.0 amd64 1.0.1g-1 [1.008 kB]
Réception de : 2 http://ftp.be.debian.org/debian/ jessie/main openssl amd64 1.0.1g-1 [664 kB]
# Correctif pour FreeBSD
Posté par Anonyme . Évalué à 0.
http://lists.freebsd.org/pipermail/freebsd-security/2014-April/007417.html
[^] # Re: Correctif pour FreeBSD
Posté par Zenitram (site web personnel) . Évalué à 7.
Correctif?
Hum… un correctif n'enlève pas de fonctionnalités.
c'est plutôt un hot-fix avec regressions en attendant un meilleur patch (qui n'enlèvera pas de fonctionnalité).
[^] # Re: Correctif pour FreeBSD
Posté par Anonyme . Évalué à 1. Dernière modification le 08 avril 2014 à 20:44.
Heu oui en effet… trop tard pour éditer.
En plus il ne suffit pas de relancer un make. Bref, FreeBSD, quand ça touche le système de base, c’est chiant, y’a pas à dire.
[^] # Re: Correctif pour FreeBSD
Posté par JGO . Évalué à 2.
Note que les utilisateurs de gentoo et en particulier de gentoo freebsd peuvent réinstaller sans la fonctionnalité avec « USE="-tls-heartbeat" emerge openssl ». C'est d'ailleurs mentionné dans l'alerte de sécurité.
[^] # Re: Correctif pour FreeBSD
Posté par Anonyme . Évalué à 2. Dernière modification le 08 avril 2014 à 20:49.
Ah, un correctif (un vrai cette fois) est passé sur -releng et -stable. Plus qu’à attendre les builds.
Sinon il y a aussi WITH_OPENSSL_PORT=yes dans /etc/make.conf, et à utiliser avec poudriere également quand on l’utilise. Le port a été corrigé bien plus vite.
# et les "Application Serveur" ?
Posté par gcr . Évalué à 2.
la faille a un impact sur Apache (utilise les librairies de openssl) mais est-ce que JBoss et Tomcat sont impactés ?
Je veux dire par là, est-ce que un Tomcat avec SSL activé à besoin d'une nouvelle version de la librairie de OpenSSL (LD_LIBARY_PATH) et redemarrage ?
Java utilise le package "java.security" mais est-ce une reimplmentation ssl ou la lib openssl est utilisé ?
merci pour vos lumières
Gilles
[^] # Re: et les "Application Serveur" ?
Posté par Vincent . Évalué à 1.
https://docs.jboss.org/jbossweb/7.0.x/ssl-howto.html :
Oui si tu utilises APR.
# La crypto des Unix libre owned par la nsa
Posté par nanard . Évalué à 2. Dernière modification le 09 avril 2014 à 22:36.
Et vous avez lue ça http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ ?
De ce que j'ai compris, et vous pouvez me reprendre, mon anglais lue est assez limite, tout les Unix libre sont nivelé par le bas par la nsa au niveau cryptographique.
Il est dis que la faille dont on parle dans cette news est inadmissible, presque une erreur de débutant d'avoir ce genre de probléme, donc voulue.
Une note d'espoir quand même, avoir un niveau cryptographique robustre est possible, mais faut être gouru niveau 6 (sans blague!).
Si des gens sont motivé pour faire le sous titrage de la vidéo d'Assange et publier ça histoire de nous faire découvrir ce qu'il a à dire, nous leur serions reconnaissant.
Allez tous vous faire spéculer.
# redémarrage des services sur Debian testing
Posté par Anonyme . Évalué à 5.
à noter que debian testing vient d'ajouter la détection des services dépendant de openssl pour les relancer lors de l'installation du paquet: une initiative très appréciable qui rendra les futures mises à jours beaucoup plus aisées
# Debian compromis par la NSA ?
Posté par Xavier G. . Évalué à 4. Dernière modification le 09 avril 2014 à 22:48.
Je ne vais pas ouvrir un journal juste pour ça, d'autant que l'info est connexe à celle-ci (Elie vient de poster au-dessus le même lien pendant que je rédigeais ma réponse), et que sans preuve formelle on est pour le moment plutôt dans le domaine du troll ultime que de la démonstration, mais cette accumulation de failles critiques peut rendre parano et ouvrir la porte à la théorie du complot.
En effet, outre Heartbleed (avec les polémiques sur sa découverte, la date de diffusion publique…) et les deux autres listées en fin de dépêche (Gnu TLS, Apple), celle plus ancienne touchant déjà OpenSSL sur les alertes Valgrind, voilà maintenant que ressort la rumeur du "contrôle" de Debian et autres distributions Linux par la NSA, conférence donnée par le fondateur de Wikileaks Julian Assange :
http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/
http://cyrille-borne.com/post/2014/04/09/assange-est-il-un-trolleur-debian-est-elle-compromise
En l'état bien sûr, impossible d'affirmer quoi que ce soit, à moins que le Guardian ne publie prochainement un slide issu des documents sourcés par Snowden - là je devrais être bon question mots clés sensibles !
De plus, nul besoin d'une taupe gouvernementale pour introduire un bug, nulle nécessité non plus de croire que c'est forcément volontaire, au contraire.
Le code évoluant constamment, à tout moment il peut y avoir des régressions, la sécurité devenant de plus en plus vitale les programmes open-source sont régulièrement audités attentivement, d'où la découverte des failles majeures. Toujours est-il que cela fait beaucoup en peu de temps et que cela alimente les suspicions.
Mais espérons que cela fasse progresser la sécurisation globale des serveurs et outils informatiques, tout comme la prise de conscience des usagers et entreprises de veiller à leur intégrité (surveillance, mise à jour, sauvegardes).
[^] # Re: Debian compromis par la NSA ?
Posté par Renault (site web personnel) . Évalué à 10.
Il est pratiquement certains que la NSA a tenté de réduire la sécurité logicielle que ce soit dans le code mais aussi dans les normes eux mêmes. Et il est tout aussi possible que d'autres États soient dans le coup.
Si cela peut paraître très inquiétant, il y a aussi des avantages à cela :
Bref, il y a de l'espoir, même si la situation est sensible.
[^] # Re: Debian compromis par la NSA ?
Posté par khivapia . Évalué à 4.
que a factorisation des nombre premiers très grands n'a pas été résolu chez eux (si solution il existe).
Pourtant ils ont recommandé de passer aux courbes elliptiques et de ne plus utiliser RSA…
En même temps il est vrai qu'ils ont poussé des courbes particulières sans dire comment elles ont été choisies (plutôt que d'utiliser un processus déterministe et vérifiable à la brainpool afin d'obtenir des paramètres non choisis tels que http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number ).
[^] # Re: Debian compromis par la NSA ?
Posté par DerekSagan . Évalué à 10.
Factoriser un nombre premier grand ou petit est effectivement un problème qui ne sera jamais résolu, par définition.
C'est un peu comme tracer 7 lignes rouges perpendiculaires entre elles…
;-)
(désolé c'était un peu facile de profiter de ton raccourci)
[^] # Re: Debian compromis par la NSA ?
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
Du moins, dans cet univers.
[^] # Re: Debian compromis par la NSA ?
Posté par Wawet76 (site web personnel) . Évalué à 9.
Dans un espace à 7 dimensions tu dois pouvoir tracer 7 lignes perpendiculaires non ?
[^] # Re: Debian compromis par la NSA ?
Posté par 2PetitsVerres . Évalué à 3. Dernière modification le 10 avril 2014 à 17:15.
Dans un espace à 7 dimensions ou plus, c'est simple.
Édit : Et mince, vieil onglet.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Debian compromis par la NSA ?
Posté par eingousef . Évalué à 5.
moi je dis ils bluffent
*splash!*
[^] # Re: Debian compromis par la NSA ?
Posté par groumly . Évalué à 1.
J'ai pas l'impression que la NSA agit dans l'interet national, plutot dans leur interet a eux.
En clair, la security du pays, ils s'en foutent, ce qui les interesse c'est d'espionner tout ce qui se dit, americain ou pas. Dans cette perspective, t'as interet a baisser la securite de tout le monde.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Debian compromis par la NSA ?
Posté par Renault (site web personnel) . Évalué à 1.
Leur but est d'avoir plus d'informations que l'ennemi. En abaissant la sécurité de tous, l'ennemi peut avoir autant voire plus d'informations qu'eux.
[^] # Re: Debian compromis par la NSA ?
Posté par Albert_ . Évalué à 4.
Oui mais vu les informations recentes l'ennemi c'est tout le monde y compris les americains. Parceque ne nous leurrons pas, certains americains et en particulier dans les spheres politiques veulent mettre des limites sur la capacites de la NSA d'espionner les americains des USA le reste ils ne veulent surtout pas changer.
Cela apporte des informations militaires mais aussi (surtout?) economique et ils s'en servent. L'ennemi economique etant bien different de l'ennemi militaire.
[^] # Re: Debian compromis par la NSA ?
Posté par lasher . Évalué à 6.
Ça va même plus loin que ça. Les membres du congres US ont commencé à s’inquiéter quand ils ont appris que leurs conversations (via email ou téléphone) étaient susceptibles d’être espionnées. Avant ça, ils n'en avaient rien à foutre, citoyens US ou pas.
[^] # Re: Debian compromis par la NSA ?
Posté par khivapia . Évalué à 2. Dernière modification le 13 avril 2014 à 22:13.
En abaissant la sécurité de tous, l'ennemi peut avoir autant voire plus d'informations qu'eux.
La NSA est plus maligne que ça : pour le générateur d'aléa troué, seule la NSA peut profiter de la vulnérabilité (en connaissant la clef privée, c'est un système quasi à clef publique). Les autres peuvent se brosser.
Dans l'affaiblissement de Notes il y a quelques années, c'était la même chose : les clefs 128 bits étaient séparées en 40 bits d'un côté, 88 autres qui étaient chiffrés sous une clef publique NSA. Seule la NSA pouvait déchiffrer, la sécurité du bousin restait de 128 bits pour le reste du monde.
[^] # Re: Debian compromis par la NSA ?
Posté par claudex . Évalué à 2.
Non, n'importe qui qui fait des recherches sur ce générateur peut tomber sur la solution qui l'affaiblit. Et rien ne dit qu'il va l'utiliser à bon escient.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian compromis par la NSA ?
Posté par khivapia . Évalué à 6.
Non. L'affaiblissement du générateur d'aléa (EC_DRBG) est lié à un problème similaire à une clef publique : n'importe qui peut comprendre le problème, mais récupérer la solution qui l'affaiblit sans avoir l'info secrète de la NSA revient à résoudre un problème de logarithme discret sur courbe elliptique, c'est-à-dire à savoir péter à peu près tous les systèmes actuellement en cours de déploiement.
Cf les slides http://www.wired.com/images_blogs/threatlevel/2013/09/15-shumow.pdf (slide 8, deuxième point).
Dans ce cas, la NSA a affaibli le standard pour elle seule.
[^] # Re: Debian compromis par la NSA ?
Posté par Krunch (site web personnel) . Évalué à 2.
Du moins tant que la clef n'est pas compromise par d'autre entites.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Debian compromis par la NSA ?
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
Attention la NSA doit à la fois protéger les institutions Américaine des intrusions et s'introduire dans les institutions étrangères, sauf que le marché informatique est mondial et donc ces institutions utilisent les mêmes logiciels. En affaiblissant les logiciels libres, elles risques d'affaiblir la sécurité des institutions Américaine.
[^] # Re: Debian compromis par la NSA ?
Posté par Krunch (site web personnel) . Évalué à 10.
C'est amusant cette hypothèse qui implique que la NSA n'a pas d'intérêt à s'infiltrer dans les systèmes de sociétés états-uniennes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Debian compromis par la NSA ?
Posté par Gof (site web personnel) . Évalué à 1.
Des étrangers pourraient prendre connaîssence de la faille, et voler des informations précieuses à des compagnies états-uniennes.
# Et les systèmes embarqués ?
Posté par Renault (site web personnel) . Évalué à 10.
On parle beaucoup du web en lui même, mais peu des périphériques embarqués qui peuvent être aussi touchés mais dont les mises à jour sont plus délicates : téléphones, télévisions, boxs Internet, NAS, autres… Ces périphériques peuvent contenir cette bibliothèque et sont des éléments contenant potentiellement de nombreuses données personnes voire 'accès intégral à d'autres périphériques.
Pourtant les gens semblent se concentrer uniquement sur des services web, alors qu'ils ont (normalement) tous corriger leur infrastructure, ces périphériques ce serait une autre paire de manche…
[^] # Re: Et les clients ?
Posté par SaintGermain . Évalué à 5.
Et on parle aussi beaucoup des serveurs, mais moins des clients vulnérables :
what-clients-are-proven-to-be-vulnerable-to-heartbleed
Personnellement j'avais bien pensé à patcher mon serveur mais pas mes ordinateurs personnels (wget, git…).
[^] # Re: Et les clients ?
Posté par TilK . Évalué à 6.
En me servant de pacemaker, je me suis aperçu par exemple que le navigateur "samsung" de ma tablette android était vulnérable. Et hop, l'historique de navigation et les cookies qui fuitent vers le serveur.
Ça fait peur…
# Tester sa clé privée
Posté par Spack . Évalué à 10.
Enfin un service utile. On peut au moins tester si notre clé privée a fuité grace à ce site http://privatekeycheck.com/. '-_-
[^] # Re: Tester sa clé privée
Posté par Renault (site web personnel) . Évalué à 6.
Bonne initiative, mais j'aurais préféré une version pour tester le code bancaire et le mot de passe…
[^] # Re: Tester sa clé privée
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Alice et Bob me chargent de te dire qu'ils sont très très fâchés avec tout ça…
[^] # Re: Tester sa clé privée
Posté par Spack . Évalué à 3.
C'est Charlie qui va être content…
[^] # Re: Tester sa clé privée
Posté par vlamy (site web personnel) . Évalué à 4.
Rhoo, c'est pas gentil pour les naïfs ! Ne me dite pas qu'il n'y en a pas, on voit bien des développeurs faire des commit de leurs clefs privées.
C'est presque du phishing là !
[^] # Re: Tester sa clé privée
Posté par Atem18 (site web personnel) . Évalué à 3.
Ouais enfin, je ne sais pas si "naifs" est le juste terme pour qualifier des personnes pareilles.
# Debian stable wheezy à jour mais version 1.0.1e
Posté par mazert . Évalué à 0.
Je viens de mettre à jour debian stable wheezy, qui me propose une mise a jour d'openssl. Sauf qu'en regardant la version :
openssl version
OpenSSL 1.0.1e 11 Feb 2013
Etrange, alors que la 1.0.1e fait partie des version vulnérable.. chez vous c'est pareil ?
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par claudex . Évalué à 6.
Si tu regarde mieux, c'est la version 1.0.1e+ deb7u6 qui inclut le patch de correction.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par mazert . Évalué à -1.
Ah… et comment peut-on savoir qu'il s'agissait d'un patch ? en recherchant l'occurence "deb7u6" sur le web pour en obtenir des infos, ou il y a t'il une signification spécifique derrière ça ?
On a pu me faire remarquer qu'avec un openssl version -b :
*built on: Tue Apr 8 10:05:11 UTC 2014
Du coup d'après la date, ça corrige bien le bug.
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par claudex . Évalué à 7.
ou
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par jyes . Évalué à 3.
"deb7u6" = Debian 7 (Wheezy) update 6.
Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par tyoup . Évalué à 2.
moi qui croyait que c'était la version de debuG
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.