Journal : Vulnérabilité Debian
Posté par snt () le 13 mai 2008
0
C'est énorme : La version d'openssl packagé par debian génère des clés de chiffrement prévisibles ! Donc non seulement, il faut mettre à jour vos machines, mais en plus il faut regénérér toutes vos clés, ou alors il ne faudra pas pleurer après.Plus d'infos sur :
http://lists.debian.org/debian-security-announce/2008/msg001(...)
> Lire le journal (97 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #931121.
Run by 
Cette page a été générée par Templeet en 0.0772s (dont 0.0076 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
détails techniques et exploits
http://it.slashdot.org/comments.pl?sid=551636&cid=233926(...)
Donc apparemment ça viendrait du fait que le mainteneur qui voulait faire taire Valgrind a « corrigé anticipativement » un peu trop large. « Oh tiens, ça ressemble à la ligne qui génère un warning, on va la supprimer aussi. »
Et pour les kiddies, il y a de quoi s'amuser par là (entre autres) : http://metasploit.com/users/hdm/tools/debian-openssl/
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: détails techniques et exploits
Perso je trouves que c'est surtout un tres bon exemple du risque des forks et de la difficulte de maintenir un soft dont on ne comprend pas le code.
Si ca se trouve le gars est un developpeur cale, mais quand tu ne maitrise pas le code sur lequel tu bosses(techno peu connue / complexe / grosse base de code...) t'as beau etre cale les catastrophes sont possibles et probables.
[^]Re: détails techniques et exploits
Heu non, faut pas exagerer, c'est pas par ce qu'il se trouve que ce bug a été introduit par un mainteneur de package qu'il faut en conclure des trucs sur le risque des forks. C'est une erreur, ca arrive, et ca aurait très bien pu arriver à un developpeur d'openssl aussi.
Si on regarde les alertes de sécurité, 99% proviennent de bugs dans les logiciels upstream, c'est par par ce qu'il y a un problème une fois avec un patch ajouté par le mainteneur du package qu'il faut en conclure n'importe quoi.
[^]Re: détails techniques et exploits
enfin la même ceux qui maitrisait le code (les dvp d'openssl) on dis que pour eux c'était ok comme modif.
Comme quoi ...
Des fois , meme si tu es calé, tu connais le code, tu as las doc, des catastrophes sont possibles et probables.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: détails techniques et exploits
> enfin la même ceux qui maitrisait le code (les dvp d'openssl) on dis que pour eux c'était ok comme modif.
Arrêtes de répéter ça, ce n'est pas vrai.
Et si c'est vrai, c'est uniquement pour une version de debug.
Hors le mainteneur n'a pas fait sa bourde uniquement sur la version de debug.
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
[^]Re: détails techniques et exploits
Arrêtes de répéter ça, ce n'est pas vrai.
Certainement plus que dire (répeter jusqu'a plus soif devrais je dire)
"il savait absolument pas ce qu'il faisait", vu qu'il a pointé du doigt le problème d'entropie du code.
Et si c'est vrai, c'est uniquement pour une version de debug.
pas totalement vrai ce que tu dis, il acceptait pour le debugging AUSSI des applications contenants openssl.
Regardons donc les liens que j'ai donné, on voit :
Not much. If it helps with debugging, I'm in favor of removing them.
> (However the last time I checked, valgrind reported thousands of bogus
> error messages. Has that situation gotten better?)
I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
GNU/Linux 'sid' with valgrind version 3.1.1 was able to debug some
application using both TLS/SSL as S/MIME without any warning or error
about the OpenSSL code. Without -DPURIFY you're indeed flooded with
warnings.
So yes I think not using the uninitialized memory (it's only a single
line, the other occurrence is already commented out) helps valgrind.
Oh tiens ca alors, ca parle pas que du debugage interne à openssl mais aussi de tous les autres codes qui utilisent openssl (et qui donc ne travaillent pas sur une version d'openssl de debug. Quand tu debug ton code, tu travaille pas sur une version de debug de libc6 , si ?)
alors je suis d'accord que le dvp debian a fait des merdouilles, que les dev d'openssl ont pas forcément vu tous les problèmes, mais un moment faut arrêter de dire "Il sait absolument pas ce qu'il faisait", et "il a tout fait tout seul dans son coin".
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
Pas forcément : il n'y a pas de bug a proprement parlé. La criticité de l'opération est très faible. Donc on voit passer sa sur la mailing list, on se dis "a pas con", et finalement on oublie de reporter ça. Comme ça ne corrige pas de bugs à proprement parler, on oublie relativement facilement, et on se précipite pas pour pousser tout upstream.
La ou les dvp de debian ont merdé, c'est lors du push des patchs vers l'upstream, et ca je suis bien d'accord.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: détails techniques et exploits
> "il savait absolument pas ce qu'il faisait"
QU'IL NE LE FASSE PAS !
> il acceptait pour le debugging AUSSI des applications contenants openssl.
Il a dit "I'm in favor of removing them". Il n'a pas dit "OK, ça roule ma poule".
Il y a un autre développeur OpenSSL qui répond :
On May 1, 2006 03:14 pm, Kurt Roeckx wrote:
> The code in question that has the problem are the following 2
> pieces of code in crypto/rand/md_rand.c:
>
> 247:
> MD_Update(&m,buf,j);
>
> 467:
> #ifndef PURIFY
> MD_Update(&m,buf,j); /* purify complains */
> #endif
There's your first clue, build with -DPURIFY :-)
Cheers,
Geoff
Mais le "247: MD_Update(&m,buf,j);" est devenu "/* MD_Update(&m,buf,j); */" sans que le développeur OpenSSL le savent.
Regarde la version 199 :
http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
C'est :
/** Don't add uninitialised data.
MD_Update(&m,buf,j); MD_Update(&m,buf,j);
*/
Ceci n'a jamais été validé. Et c'est ça qui pose problème.
> I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
> etc
Il n'est pas développeur OpenSSL.
Le mainteneur Debian a fait une connerie. Je ne demande pas une "lapidation". Mais il a fait une connerie et ça peut arriver à toi ou à moi.
Il faut reconnaitre qu'il a fait une connerie. Je ne demande pas qu'il arrête d'être mainteneur !
Si tu ne reconnais pas qu'il y a connerie, tu ne remets pas en cause. Si tu reconnais qu'il y a une connerie, ben tu ne mets pas en place une solution. Par exemple il ne faut plus toucher au "noyau" OpenSSL sans que le patch soit approuvé en upstream (donc il doit être upstream). Etc.
Quand MS fait une connerie, on ne lui cherche pas d'excuses bidons. MS a fait une connerie, point barre. (Ici il faut évidemment distinguer "connerie" de manoeuvre volontairement mal intentionnée).
Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
C'est inacceptable.
[^]Re: détails techniques et exploits
> "il savait absolument pas ce qu'il faisait"
QU'IL NE LE FASSE PAS !
euh .. tu sais voir l'ironie ?
Visiblement pas.
bon pour le reste tu es de mauvaise foi
(- prendre la toute premiere réponse , ou c'est meme marqué "first clue" , et dire "tu vois que c'est que pour le debug", sans prendre en compte les reste du messages
- dire "les dvp d'openssl savait pas ce qu'il fasait alors qu'il avait expliqué , ...
- ne pas savoir lire (inverser celui qui dis "pour moi pas de blem" et celui qui dis "j'ai fait des test")
et je ne perdrais pas plus de temps sur ce sujet avec toi.
Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
Arrête de fumer pépé, et apprend à lire.
Ce que je dis c'est que le problème est partagé, et pas seulement celui du "bouh méchant dvp debian qui sait pas faire son boulot".
C'est inacceptable.
Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian que tu aime pas , parce qu'ils sont pas de fedora ?
Taper sur les gens dont tu arrive pas à comprendre les commentaires ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: détails techniques et exploits
> euh .. tu sais voir l'ironie ?
Désolé :-)
J'avais vu que j'avais écrit une connerie, mais j'ai oublié de corriger.
> bon pour le reste tu es de mauvaise foi
Non.
> Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian
L'erreur de Debian n'est pas innaccèptable. Ne pas la reconnaitre l'est.
[^]Re: détails techniques et exploits
Ne pas la reconnaitre l'est.
Je la reconnais, mais pas en disant "C'est que des gros naze tout est de leur faute".
Par ex je suis 100% d'accord avec l'auteur d'un blog donné plus bas par Jean-Philippe Garcia Ballester
http://blog.drinsama.de/erich/en/linux/2008051401-debian-ope(...)
Il indique bien que debian a fait des fautes, mais certainement pas "fait absolument n'importe quoi".
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: détails techniques et exploits
Et si c'est vrai, c'est uniquement pour une version de debug.
Ce n'est pas ce que signifie "If it helps with debugging, I'm in favor of removing them. " que je traduit par "si ça aide au débuggage, je suis d'accord pour les supprimer". Et non pas "je suis d'accord pour les supprimer en version debug".
[^]Re: détails techniques et exploits
Sauf que dans son message :
- il parle de retirer des erreurs valgrind pour aider à debugger
- il ne precise pas qu'il est mainteneur debian, ou que ces modifications sont destinées à etre redistribuées à beaucoup de monde
- il ne montre pas un vrai patch, il cite juste 2 lignes identiques avec numeros de lignes, en précisant que ces lignes posent probleme avec valgrind, ce qui est faux, seule une des 2 lignes pose probleme (celle qui peut etre retirée sans problème, l'autre non)
Compte tenu de tout ca :
- il est facile de croire que la personne souhaite simplement se recompiler un openssl pour debugger quelquechose
- il est facile de croire qu'il parlait uniquement de la ligne utilisant de la memoire non initialisée (la réponse est parfaitement correcte dans ce cas la)
- n'ayant pas précisé que cette modification était critique (déstinée à etre redistribuée à beaucoup de monde), la personne qui répond ne prend pas forcement le temps de verifier que toutes les affirmations sont exactes
[^]Re: détails techniques et exploits
C'est tout à fait exact et je ne prétends pas dire qu'il n'y a pas eu d'erreur, néanmoins, je pense que le mainteneur Debian n'est pas le seul en cause, sans doute que le code n'était pas aussi clair qu'il aurait dû l'être pour cette partie sensible (voir à ce propos cette réaction : http://www.aigarius.com/blog/2008/05/14/too-similar-to-be-di(...) ).
Comme dans tous les problème de sécurité, c'est une ensemble de déficiences qui sont à la source du problème :
- Au départ, le code n'est pas suffisamment explicite et utilise entre autre une variable non initialisée comme source d'aléa
- Le mainteneur veut supprimer les erreurs remontées
- Il demande conseil sans expliquer suffisamment ce qu'il veut faire
- Sur la mailing-list openssl-dev on ne lui explique pas suffisamment le fonctionnement
- Il corrige et supprime un peu trop de code (le mieux est l'ennemi du bien)
- Il est tout seul comme mainteneur d'openssl (en fait ils sont 2 mais il semble que le deuxième soit trop occupé) alors que ça fait 2 ans qu'il demande de l'aide ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498 )
- Il n'y a pas de revue de la security team pour les packages sensible (manque de moyens et de bonnes volontés sans doute).
C'est clair qu'il a fait une grosse boulette, mais le processus a certainement manqué de quelques fusibles.
PS: la liste des erreurs n'est pas exhaustive, on pourrait noter un manque de remontée upstream comme il a déjà été dit
[^]Re: détails techniques et exploits
a « corrigé anticipativement » un peu trop large. « Oh tiens, ça ressemble à la ligne qui génère un warning, on va la supprimer aussi. »
C'est pas comme si a pas demandé d'avis aux dvp openssl, et c'est pas comme si ils ont pas dis "si ca peut faciliter le debug, pour nous c'est OK".
De plus j'ai quand même du mal à ce qu'on considère la mémoire non initialisé comme du "bon" aléas. Que ca rajoute un peu d'aléas je peux comprendre(et encore, suffit de mettre toute la mémoire dispo a zero (programme utilisateur) avant de lancer openssl!, et hop on a une jolie faille.
ex : je sais que le serveur X génère des clés le soir à 22h. J'ai un compte utilisateur sur ce serveur.
juste avant 22h, je lance un programme qui va écrire des zéro sur toute la mémoire qu'il peut initialiser, puis ensuite la rend.
La probabilité qu'openssl va demander de la mémoire que j'ai initialiser peut etre assez grande (suivant la mémoire dispo, ce qui tourne, ...))
, mais que tout l'aléa dépende de ça, j'avoue que j'ai plus de mal. C'est pas comme si il y avait /dev/random si on veut de l'aléa un peu plus correct ...
Enfin je suis pas un expert, loin de la, et j'ai pas regardé ce que fait openssl mais ca m'a fait tiquer quand meme.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: détails techniques et exploits
mais que tout l'aléa dépende de ça, j'avoue que j'ai plus de mal.
Ce n'est pas du tout le cas. Voir par exemple : http://blog.drinsama.de/erich/en/linux/2008051401-debian-ope(...)
[^]Re: détails techniques et exploits
thanks ;)
(en plus le gars qui fait le blog est tout a fait de mon avis donc ca peut etre que bien XD )
Subete ga wakatta toki…watashi ga anta wo korosu.