Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
2179 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  OpenSSL compromis sur Debian(et ubuntu \o/)

 



 Mot :   Pseudo :  
 
 Page :   1  2  3  4
Page Précédente
Auteur Sujet :

OpenSSL compromis sur Debian(et ubuntu \o/)

n°1041544
masklinn
í dag viðrar vel til loftárása
Posté le 13-05-2008 à 18:38:49  profilanswer
 

http://lists.debian.org/debian-sec [...] 00152.html

Citation :

Luciano Bello discovered that the random number generator in Debian's
openssl package is predictable.  This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166).  As a
result, cryptographic key material may be guessable.
 
This is a Debian-specific vulnerability which does not affect other
operating systems which are not based on Debian.  However, other systems
can be indirectly affected if weak keys are imported into them.
 
It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch.  Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.



Sarge n'est pas affectée, tout ce qui est plus récent (etch, testing et unstable) l'est.
 
Allez voir l'alerte pour des outils permettant de tester la compromission de vos clés et les méthodes de rattrapages (globalement, dégager toutes vos clés et les recréer).
 
Alterte Ubuntu confirmant qu'elle est également compromise à partir de Feisty (7.04) et jusqu'aux versions récentes d'Intrepid Ibex: http://www.ubuntu.com/usn/usn-612-1


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
mood
Publicité
Posté le 13-05-2008 à 18:38:49  profilanswer
 

n°1041608
Xavier_OM
Talking seagull lawyer, bitch
Posté le 13-05-2008 à 22:58:15  profilanswer
 

Dans le genre grosse faille, ca se pose (remarque l'exploit du kernel pour usurper les droits root c'était pas mal aussi)

 

De ce que je comprends, openssl utilise l'état non initialisé de la mémoire (à l'allocation donc) comme source de random.
Mais faire ça lève des warnings dans valgrind (détecteur de fuite mémoire), et donc pour corriger le problème le paquet a été patché, la mémoire initialisée à zéro avant usage. Et du coup une des sources de random n'est pas random du tout :/
http://www.links.org/?p=327
 
Un nettoyage de code assez malheureux, mais si on vérifie ici : http://marc.info/?t=114651088900003&r=1&w=2
on voit qu'en gros côté Debian on a vu que cela ferait moins d'entropie et côté openssl on a dit que malgré tout ce n'était pas forcément à jeter si cela aidait au debug.

 

edit :
plus d'infos http://www.aigarius.com/blog/2008/ [...] different/
plus d'infos http://reddit.com/info/6j7a9/comments/c03zxko

 

La grande question : le générateur est plus prédictible, mais dans quelle mesure cela rend-il une attaque possible ?
Si c'est juste lié à la clef générée lors de la négociation Diffie-Hellman, elle change à chaque connexion ssh alors...
Ce qui est sûr c'est que le "détecteur" de clefs faibles cité dans la Debian Security Alert détecte très très rapidement si la clef est faible ou pas.

 


Il faut :
- upgrader openssl
- régénerer ses clefs ssh clients si on fait du ssh, et les déployer partout où elles servent.
- régénerer ses certificats X509 si on fait du https
- régénerer les clefs du server openssh et le redémarrer.

mv /etc/ssh/ssh_host_{dsa,rsa}_key* /some/place/else
dpkg-reconfigure -plow openssh-server

 

Bref tout ce qui est en relation avec openssl :/

 

Pour bien faire les choses il faudrait aussi changer les password qui ont été tapés à un moment dans une session ssh trop faible.

 

Inconvénient Debian/Ubuntu/dérivés : il y a un manque de contrôle qualité dans les patch appliqués. Si une distribution fait un patch, il faut soit le faire remonter au développeur qui maîtrise le sujet, soit avoir une procédure très stricte de validation. On a besoin d'un système simple pour passer en revue ce genre de trucs, surtout sur les paquets critiques, et surtout si on est une distribution qui patche tout tout le temps (ce qui est le cas de Debian).

 


Inconvénient du système à plus grande échelle : si les développeurs upstream se plantent (si le nouveau codeur récemment arrivé fait de la merde), on ne le verra pas sans contrôle qualité (revue du code ?)

 

Avantage du système : la faille est publiée, la correction aussi. C'est toujours mieux que de résoudre le problème discrètement et sans communiquer dessus.


Message édité par Xavier_OM le 14-05-2008 à 09:44:59

---------------
"La planète crève, c’est sûr, j’l’ai tweeté hier soir."
n°1041612
masklinn
í dag viðrar vel til loftárása
Posté le 13-05-2008 à 23:12:24  profilanswer
 

Accessoirement, il est également conseillé de passer l'outil fourni dans le lien initial sur les clés même si ce n'est pas un système basé sur debian: toute clé créée sous debian ou ubuntu et importée est également compromise


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041623
Profil sup​primé
Posté le 14-05-2008 à 00:00:58  answer
 

Adieu, monde cruel [:vyse]

n°1041627
THRAK
- THR4K -
Posté le 14-05-2008 à 01:26:18  profilanswer
 

C'est clairement une sacrée merde cette compromission avec OpenSSL.  :fou:  :/
 
Faudra vraiment que les dev communiquent mieux et davantage avec l'upstream à l'avenir, surtout pour les paquets de ce type... le cas présent est une leçon magistrale en la matière. En attendant ça va être un beau bordel dans les jours à venir (niveau re-génération de clés et certifs on va pas être déçus...) ; une histoire qui risque de faire grand bruit dans le milieu...  :o


---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
n°1041655
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 09:18:22  profilanswer
 

pour rebondir : http://blog.drinsama.de/erich/en/l [...] l-desaster

 

La mémoire non initialisée n'est pas forcemment "totallement" initialisée de ce que je comprends... Si le compilo a des options spécifiques alors on peut avoir le même comportement..

 

Grand bruit je sais pas... parce que c'est surtout une faille "théorique"... qu'il sera difficile (impossible ?) d'exploiter... et regénérer des centaines de clés [:pingouino] je suis carrément pas chaud...

 

edit : il n'y a que les gens qui ne font rien qui ne se trompent pas... pour le coup je rejoins lucas nussbaum. Les devs d'openssl ont aussi le droit de commenter leur code, surtout aux endroits "litigieux" au niveau sens.

Message cité 2 fois
Message édité par black_lord le 14-05-2008 à 10:14:34

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041678
sligor
Calme, mais pas trop
Posté le 14-05-2008 à 10:12:52  profilanswer
 

Ca serait intéressant d'avoir plus d'infos sur la diminution de l'entropie du RNG dû à la faille,  si on perd quelques bits sur 256b c'est pas trés grave, si on passe de 256 à 32 là c'est plus gênant.

n°1041679
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 10:15:05  profilanswer
 

en faisant qq recherches il apparait que les clés peuvent apparemment subir assez rapidement une analyse :/


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041682
masklinn
í dag viðrar vel til loftárása
Posté le 14-05-2008 à 10:20:23  profilanswer
 

black_lord a écrit :

edit : il n'y a que les gens qui ne font rien qui ne se trompent pas... pour le coup je rejoins lucas nussbaum. Les devs d'openssl ont aussi le droit de commenter leur code, surtout aux endroits "litigieux" au niveau sens.


Ouais enfin d'un autre côté quand on connaît rien en crypto on va pas modifier du code de crypto juste pour faire taire un warning dans valgrind :sweat:

 

edit: et si on le fait quand même, on upstream le patch afin que les gens qui s'y connaissent puissent le voir et l'analyser avant de l'appliquer sans en parler aux responsables [:pingouino]


Message édité par masklinn le 14-05-2008 à 10:21:22

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041686
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 10:31:00  profilanswer
 

on est d'accord :jap:


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
mood
Publicité
Posté le 14-05-2008 à 10:31:00  profilanswer
 

n°1041689
Taz
bisounours-codeur
Posté le 14-05-2008 à 10:41:17  profilanswer
 

Moi j'y comprends rien à cette DSA: si le PRNG d'openssl repose uniquement sur de la mémoire pas initialisée plutôt que sur des choses comme /dev/random alors c'est openssl qu'il faut jeter.

n°1041690
Taz
bisounours-codeur
Posté le 14-05-2008 à 10:44:17  profilanswer
 

black_lord a écrit :

pour rebondir : http://blog.drinsama.de/erich/en/l [...] l-desaster
 
La mémoire non initialisée n'est pas forcemment "totallement" initialisée de ce que je comprends... Si le compilo a des options spécifiques alors on peut avoir le même comportement..
 
Grand bruit je sais pas... parce que c'est surtout une faille "théorique"... qu'il sera difficile (impossible ?) d'exploiter... et regénérer des centaines de clés [:pingouino] je suis carrément pas chaud...


ouais alors là je suis bien d'accord avec toi. Le non-initialisé, ça peut souvent contenir que du 0 ou un motif, quelque chose de très prévisible justement. Les dev d'openssl a part vaner sur debian ne font pas de véritable analyse du problème. ça sent vraiment mauvais openssl.

n°1041693
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 10:51:23  profilanswer
 

Taz a écrit :

Moi j'y comprends rien à cette DSA: si le PRNG d'openssl repose uniquement sur de la mémoire pas initialisée plutôt que sur des choses comme /dev/random alors c'est openssl qu'il faut jeter.


 
ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041696
sligor
Calme, mais pas trop
Posté le 14-05-2008 à 10:57:07  profilanswer
 

black_lord a écrit :


 
ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...


L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.

n°1041698
Taz
bisounours-codeur
Posté le 14-05-2008 à 10:58:22  profilanswer
 

black_lord a écrit :

 

ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...


je croyais que debian voulait balancer openssl pour des problèmes de licences, il y a peut être pas que ça en fait.
C'est une escroquerie cette alerte: je vois pas en quoi dépatcher le bouzin corrige le problème de sécurité. Bien malheureux ceux qui se croient à l'abri avec du code comme ça.

 

Je viens de pinger sur http://bugs.debian.org/cgi-bin/bug [...] bug=363516 pour avoir des infos.

Message cité 1 fois
Message édité par Taz le 14-05-2008 à 11:13:17
n°1041704
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 11:14:43  profilanswer
 

sligor a écrit :


L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.


 
A d'autres... Tous les unix ont des /dev/*random*...


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041705
Taz
bisounours-codeur
Posté le 14-05-2008 à 11:15:33  profilanswer
 

sligor a écrit :


L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.


C'est sinistrement stupide comme approche.

n°1041707
gug42
Posté le 14-05-2008 à 11:20:40  profilanswer
 

Salut les gens,

 

Bon voila, je n'arrive pas à bien estimer le risque ...
Est ce si grave ?
Est ce rapide de compromettre une connexion ssl ? (par exemple https  ou ssh via mot de passe) ?

 

D'après Black lord tout ca est très théorique ?

 

Car regénérer les clefs de tout les serveurs va me prendre du temps beaucoup de temps (voir trop) :
- sshd (que la connexion soit par mot de passe ou par clef)
- openvpn
- certificats https

Message cité 1 fois
Message édité par gug42 le 14-05-2008 à 11:23:14
n°1041710
Taz
bisounours-codeur
Posté le 14-05-2008 à 11:25:56  profilanswer
 

Bah on est comme toi, on ne sait pas quoi penser. La DSA ne donne pas d'indice sur la faisabilité d'une attaque, et surtout quand on voit le correctif/dépatch, on se met à penser que patch ou pas, les clefs/certificats générés avec openssl sont de qualité extrêmement médiocre.

n°1041711
skateinmar​s
Posté le 14-05-2008 à 11:26:36  profilanswer
 

black_lord a écrit :


 
A d'autres... Tous les unix ont des /dev/*random*...


Openssl doit être dispo sur windows ?
Enfin ca empêche pas d'utiliser une source en plus la ou elle est disponible...


---------------
Feedback HAV
n°1041720
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 11:42:18  profilanswer
 

gug42 a écrit :

Salut les gens,
 
Bon voila, je n'arrive pas à bien estimer le risque ...  
Est ce si grave ?  
Est ce rapide de compromettre une connexion ssl ? (par exemple https  ou ssh via mot de passe) ?
 
D'après Black lord tout ca est très théorique ?  
 
Car regénérer les clefs de tout les serveurs va me prendre du temps beaucoup de temps (voir trop) :
- sshd (que la connexion soit par mot de passe ou par clef)
- openvpn
- certificats https


 
http://wiki.debian.org/SSLkeys
 
ça ne prends qu'une minute/serveur avec des scripts...


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041723
Le_Tolier
Hello IT ?
Posté le 14-05-2008 à 11:50:24  profilanswer
 

je voulais tester mes clefs ...  

Citation :


host:/tmp# ./dowkd.pl file /home/letolier/.ssh/id_rsa
/home/letolier/.ssh/id_rsa:1: warning: unparsable line
/home/letolier/.ssh/id_rsa:2: warning: unparsable line
/home/letolier/.ssh/id_rsa:3: warning: unparsable line
/home/letolier/.ssh/id_rsa:4: warning: unparsable line
/home/letolier/.ssh/id_rsa:5: warning: unparsable line
/home/letolier/.ssh/id_rsa:6: warning: unparsable line
/home/letolier/.ssh/id_rsa:7: warning: unparsable line
/home/letolier/.ssh/id_rsa:8: warning: unparsable line
/home/letolier/.ssh/id_rsa:9: warning: unparsable line
/home/letolier/.ssh/id_rsa:10: warning: unparsable line
/home/letolier/.ssh/id_rsa:11: warning: unparsable line
/home/letolier/.ssh/id_rsa:12: warning: unparsable line
/home/letolier/.ssh/id_rsa:13: warning: unparsable line
/home/letolier/.ssh/id_rsa:14: warning: unparsable line
/home/letolier/.ssh/id_rsa:15: warning: unparsable line
/home/letolier/.ssh/id_rsa:16: warning: unparsable line
/home/letolier/.ssh/id_rsa:17: warning: unparsable line
/home/letolier/.ssh/id_rsa:18: warning: unparsable line


---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !
n°1041724
masklinn
í dag viðrar vel til loftárása
Posté le 14-05-2008 à 11:52:02  profilanswer
 

J'ai cherché un peu plus d'infos, et apparement ça vient de ce patch: http://svn.debian.org/viewsvn/pkg- [...] /md_rand.c
 
Le problème est donc, si j'ai bien compris, dans l'ajout de données au buffer d'entropie utilisé pour seeder le PRNG.  
 
En bas, il y a l'ajout de données non-initialisées pour rendre cette seed un peu plus aléatoire parce que ça ne peut qu'améliorer le truc, mais on remarque qu'il y a un #define autour pour dégager les warnings de Valgrind ou Purify. Plutôt que de setter le flag pour dégager cette partie via le define, la personne qui a créé le patch a tout commenté. Ce bout de code ne sert qu'à rendre le pool un peu plus aléatoire, et dans tous les cas ça ne peut pas le rendre moins aléatoire.
 
Mais en haut, c'est d'après les explications que j'ai eu un ajout d'un buffer initialisé et essentiel à un seeding correct du PRNG.
 
http://www.links.org/?p=327:

Citation :

Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it.


 
Pour le détecteur de clés fuckées, il est dans le premier lien, c'est http://security.debian.org/project [...] owkd.pl.gz
 
edit: une autre explication assez complète:

Citation :

I've seen a lot of confusion here about what the patch actually did, and what the functions were supposed to do. I am not a cryptographer, or maintainer of OpenSSL, but from inspecting the code, here's what I can determine.
 
There is a set of functions in OpenSSL for initializing the pseudo-random number generator seed. They all actually end up calling the ssleay_rand_add function (you can find out more about how this is supposed to work using man RAND_add). This takes a seed value, and mixes the entropy from that seed value into its entropy pool. There is also a function for getting random data out of the pseudo-random number generator, ssleay_rand_bytes (man RAND_bytes), which is supposed to return a number of random bytes into a buffer you provide.
 
Now, ssleay_rand_bytes was actually mixing some entropy from the buffer passed in before generating random data. This isn't particularly harmful, assuming that there's already enough entropy in the pool, but isn't necessarily helpful, either; uninitialized memory won't provide all that much entropy, and there are attacks that can potentially put known data into it. There had been an ifdef to avoid doing this when using tools that detect uses of uninitialized memory, but I guess they were't using that ifdef when running under Valgrind.
 
So, according to bug #363516, Valgrind was warning about unitialized data in the buffer passed into ssleay_rand_bytes, which was causing all kinds of problems using Valgrind. Now, instead of just fixing that one use, for some reason, the Debian maintainers decided to also comment out the entropy mixed in from the buffer passed into ssleay_rand_add. This is the very data that is supposed to be used to see the random number generator; this is the actual data that is being used to provide real randomness as a seed for the pseudo-random number generator. This means that pretty much all data generated by the random number generator from that point forward is trivially predictable. I have no idea why this line was commented out; perhaps someone, somewhere, was calling it with uninitialized data, though all of the uses I've found were with initialized data taken from an appropriate entropy pool.
 
So, any data generated by the pseudo-random number generator since this patch should be considered suspect. This includes any private keys generated using OpenSSH on affected Debian systems. It also includes the symmetric keys that are actually used for the bulk of the encryption, which means that any information transmitted over SSH to or from affected boxes, including passwords, should be considered to be potentially compromised.


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041728
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 11:54:25  profilanswer
 

Le_Tolier a écrit :

je voulais tester mes clefs ...  

Citation :


host:/tmp# ./dowkd.pl file /home/letolier/.ssh/id_rsa
/home/letolier/.ssh/id_rsa:1: warning: unparsable line
/home/letolier/.ssh/id_rsa:2: warning: unparsable line
/home/letolier/.ssh/id_rsa:3: warning: unparsable line
/home/letolier/.ssh/id_rsa:4: warning: unparsable line
/home/letolier/.ssh/id_rsa:5: warning: unparsable line
/home/letolier/.ssh/id_rsa:6: warning: unparsable line
/home/letolier/.ssh/id_rsa:7: warning: unparsable line
/home/letolier/.ssh/id_rsa:8: warning: unparsable line
/home/letolier/.ssh/id_rsa:9: warning: unparsable line
/home/letolier/.ssh/id_rsa:10: warning: unparsable line
/home/letolier/.ssh/id_rsa:11: warning: unparsable line
/home/letolier/.ssh/id_rsa:12: warning: unparsable line
/home/letolier/.ssh/id_rsa:13: warning: unparsable line
/home/letolier/.ssh/id_rsa:14: warning: unparsable line
/home/letolier/.ssh/id_rsa:15: warning: unparsable line
/home/letolier/.ssh/id_rsa:16: warning: unparsable line
/home/letolier/.ssh/id_rsa:17: warning: unparsable line
/home/letolier/.ssh/id_rsa:18: warning: unparsable line



 
teste plutôt tes hosts :D


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041731
Taz
bisounours-codeur
Posté le 14-05-2008 à 12:00:17  profilanswer
 

http://bugs.debian.org/cgi-bin/bug [...] bug=363516
 
Je suis désolé, mais je ne vois pas en quoi il y a un problème de sécurité. Soit le rôle de ce buffer pas initialisé est minime et ça n'a pas d'impact qu'il soit utilisé ou pas, ou qu'il ait une valeur fixe et connue, soit son rôle n'est pas minime et là le problème est plus grave.
 
Le gars de Debian dit que la sécurité d'openssl ne repose pas ce buffer pas initialisé.
 
Je ne vois pas la logique dans toutes les conclusions "jetez vos clefs". Est-ce que les clefs regénérées seront vraiment meilleures ?

n°1041736
masklinn
í dag viðrar vel til loftárása
Posté le 14-05-2008 à 12:04:23  profilanswer
 

Voir mon post de clarification


Message édité par masklinn le 14-05-2008 à 12:04:41

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041738
Xavier_OM
Talking seagull lawyer, bitch
Posté le 14-05-2008 à 12:04:31  profilanswer
 

Taz a écrit :

http://bugs.debian.org/cgi-bin/bug [...] bug=363516
 
Je suis désolé, mais je ne vois pas en quoi il y a un problème de sécurité. Soit le rôle de ce buffer pas initialisé est minime et ça n'a pas d'impact qu'il soit utilisé ou pas, ou qu'il ait une valeur fixe et connue, soit son rôle n'est pas minime et là le problème est plus grave.
 
Le gars de Debian dit que la sécurité d'openssl ne repose pas ce buffer pas initialisé.
 
Je ne vois pas la logique dans toutes les conclusions "jetez vos clefs". Est-ce que les clefs regénérées seront vraiment meilleures ?


 
 
http://wiki.debian.org/SSLkeys  > How weak?  


---------------
"La planète crève, c’est sûr, j’l’ai tweeté hier soir."
n°1041739
masklinn
í dag viðrar vel til loftárása
Posté le 14-05-2008 à 12:08:21  profilanswer
 


Et pour la première partie du post, tout à la fin, "A bit more detail" (qui dit à peu près la même chose que mon post)


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041748
Taz
bisounours-codeur
Posté le 14-05-2008 à 12:32:28  profilanswer
 

OK, ça commence à être clair.

 

En gros, en voulant faire du nettoyage, le développeur debian a:
- supprimé un morceau de code qui utilise un buffer pas initialisé. c'est pas grave puisque ce buffer est un buffer de sortie. ça ne modifie pas sensiblement la quantité d'entropie. Ca se passe dans ssleay_rand_bytes .
- supprimé un morceau de code similaire mais qui se coup si n'est pas un fignolage mais la base d'entropie du PRNG. ça se passe dans ssleay_rand_bytes. Et c'est là le problème de sécurité: le vecteur d'initialisation n'est pas utilisé.

 

La où est l'erreur, c'est que le bout de code est identique, mais avec un usage radicalement différent.


Message édité par Taz le 14-05-2008 à 12:36:15
n°1041763
skateinmar​s
Posté le 14-05-2008 à 12:57:42  profilanswer
 

Le_Tolier a écrit :

je voulais tester mes clefs ...  

Citation :


host:/tmp# ./dowkd.pl file /home/letolier/.ssh/id_rsa
/home/letolier/.ssh/id_rsa:1: warning: unparsable line



 
C'est le .pub qu'il faut lui donner :jap:


---------------
Feedback HAV
n°1041765
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 13:12:13  profilanswer
 

tous mes serveurs sont à jour, toutes mes clés ont été changées [:jar jar]

Message cité 1 fois
Message édité par black_lord le 14-05-2008 à 13:12:28

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041782
Taz
bisounours-codeur
Posté le 14-05-2008 à 14:01:27  profilanswer
 

Vu que personne ne vérifie jamais les fingerprint de ses serveurs, j'imagine le carton possible.

n°1041784
Le_Tolier
Hello IT ?
Posté le 14-05-2008 à 14:04:28  profilanswer
 

skateinmars a écrit :

 

C'est le .pub qu'il faut lui donner :jap:

 
Citation :


sd-2245:/etc/ssh# ./dowkd.pl file ssh_host_dsa_key.pub
sd-2245:/etc/ssh# ./dowkd.pl file ssh_host_rsa_key.pub
sd-2245:/etc/ssh#


qu est ce que j ai encore mal  fait ?


Message édité par Le_Tolier le 14-05-2008 à 14:04:52

---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !
n°1041787
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 14:05:25  profilanswer
 

tu as mal lu la doc :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041793
Le_Tolier
Hello IT ?
Posté le 14-05-2008 à 14:12:14  profilanswer
 

black_lord a écrit :

tu as mal lu la doc :o


 
euh [:sniperlk] cad ?
 

Citation :


sd-2245:/etc/ssh# ./dowkd.pl
usage: ./dowkd.pl [OPTIONS...] COMMAND [ARGUMENTS...]
 
COMMAND is one of:
 
  file: examine files on the command line for weak keys
  host: examine the specified hosts for weak SSH keys
  user: examine user SSH keys for weakness; examine all users if no
        users are given
  help: show this help screen
 
OPTIONS is one pf:
 
  -c FILE: set the database cache file name (default: dowkd.db)
 
dowkd currently handles OpenSSH host and user keys and OpenVPN shared
secrets, as long as they use default key lengths and have been created
on a little-endian architecture (such as i386 or amd64).  Note that
the blacklist by dowkd may be incomplete; it is only intended as a
quick check.


---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !
n°1041797
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 14:16:54  profilanswer
 

http://wiki.debian.org/SSLkeys :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041802
masklinn
í dag viðrar vel til loftárása
Posté le 14-05-2008 à 14:29:17  profilanswer
 

http://lists.debian.org/debian-sec [...] 00153.html checklist du chemin d'update


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°1041803
e_esprit
Posté le 14-05-2008 à 14:30:18  profilanswer
 


Cette page n'existe pas encore. Vous pouvez créer une nouvelle page blanche ou utiliser un modèle. Avant de créer cette page, merci de vérifier qu'une page similaire n'existe pas déjà.


Tu la crée ou pas ? :o
 
[:drapal]


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
n°1041808
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 14-05-2008 à 14:35:58  profilanswer
 

chez moi ça marche :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1041809
sligor
Calme, mais pas trop
Posté le 14-05-2008 à 14:36:48  profilanswer
 

e_esprit a écrit :


Cette page n'existe pas encore. Vous pouvez créer une nouvelle page blanche ou utiliser un modèle. Avant de créer cette page, merci de vérifier qu'une page similaire n'existe pas déjà.


Tu la crée ou pas ? :o
 
[:drapal]


problème de cache :o

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  OpenSSL compromis sur Debian(et ubuntu \o/)

 

Sujets relatifs
Gestion des ventilos sur un portable Toshiba avec DebianPXE Ubuntu - Debian
Ubuntu Party [Amiens] 24-25 mai[ubuntu] problème grub error 18
Debian: config Eth pour wifiProblème d'install debian
[ubuntu]installer les pilotes pour geforce 6600gtubuntu ne se lance pas carte ATI radeon 8500 et class Xp
[Résolu] ddclient ubuntu 8.04 
Plus de sujets relatifs à : OpenSSL compromis sur Debian(et ubuntu \o/)


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR