OpenSSL compromis sur Debian(et ubuntu \o/)

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 4 Page Suivante Page Précédente Bas de page
Auteur	Sujet : OpenSSL compromis sur Debian(et ubuntu \o/)

sligor

Reprise du message précédent :

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 ?

[:drapal]

problème de cache

Publicité

Le_Tolier

Hello IT ?

black_lord a écrit :

http://wiki.debian.org/SSLkeys

bon bah aucune de mes clef n'est relevé comme vulnerable \o/ sur ma dedi

---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !

e_esprit

done [:volta]

Environ 20 serveurs, le plus chiant étant de mettre à jour mon fichier known_hosts [:tinostar]
Ca m'a permi d'en mettre pas mal à jour au passage

Message cité 1 fois

---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.

black_lord

Modérateur
Truth speaks from peacefulness

e_esprit a écrit :

done [:volta]

Environ 20 serveurs, le plus chiant étant de mettre à jour mon fichier known_hosts [:tinostar]
Ca m'a permi d'en mettre pas mal à jour au passage

le known_hosts je l'ai rippé, ça va plus vite

idem, mises à jour dans la foulée

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Mjules

Modérateur
Parle dans le vide

Taz a écrit :

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.

J'avais la même notion, GNU TLS était pas censé remplacé openssl depuis un moment ?

---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.

P-Y

Juste pour info, voici un mail (en anglais, flemme de traduire et c'est pas super technique ) de Robert Buchholz (dev securite Gentoo) pour clarifier un peu la situation (j'ai bien evidemment demande son accord a l'auteur avant de c/c), si ca permet a certains d'y voir plus clair...

Citation :

[...]
You might have heard Debian/Ubuntu changed their Pseudo Random Number
Generator into a Predictable Random Number Generator*.

There was some confusion in IRC yesterday and today, about when SSH keys or
transmitted data should be considered compromised, and when they are safe.
Here's my understanding, please correct me if I am wrong.

First, what are the objects that we want to consider?
(1) Data transmitted over SSH (shell, keystrokes, entered passwords, file
content, X11 forwarded transmissions, etc.)
(2) Your RSA private key (the one which has "ssh-rsa" in front of the
public key)
(3) Your DSA private key ("ssh-dss" in front)

Scenario A:
You created your key on a etch, lenny or sid Debian or Ubuntu since 7.04
system after 2006-09-17.

You are screwed. Everyone has your private key (You lost 2, 3).

Scenario B:
You created your key on Gentoo, Debian sarge, etc. and only used it to
login to a vulnerable Debian/Ubuntu system.

Your private key is safe. It was used with a good PRNG on the system
where you started your connection from.

For your data (1), you should consider two cases:
B1: Someone played man-in-the-middle on the SSH server you logged in to.
This is possible if he knew of the vulnerability before all of us.
You should consider (1) as public as a telnet session.

B2: Someone recorded the *encrypted* transmission and now has the
private host key that the vulnerable machine used.
This is more subtle. In general, the Diffie Hellmann key exchange
used by SSH guarantees perfect forward secrecy. This means all data
that was transmitted cannot be decrypted afterwards, even if the
host key is compromised.
The DH exchange needs cryptographically secure random numbers,
otherwise the session key (and therefore, the encrypted data) can be
reconstructed. Since I don't know if the DH used the same weak
random number generator, I can't say whether secrecy of
transmissions (1) is guaranteed.

Scenario C:
Same as B, but you also copied your private key onto a vulnerable
Debian/Ubuntu box, and used it to establish a connection to any other SSH
server.

Due to the nature of the DSA algorithm, if an attacker knows the random
number "k" that is signed using the DSA key, it can reconstruct parts of
the key. You should consider your DSA key (3) compromised.
RSA (2) is not affected by this weakness, and is safe.

B1 and B2 applies the same way.

I hope this answers some of the questions,

Robert

* As seen here: http://www.random.org/analysis/dilbert.jpg

Message édité par P-Y le 14-05-2008 à 19:58:22

mikala

Souviens toi du 5 Novembre...

black_lord a écrit :

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

maintenant il ne te reste plus qu'a faire le tour des serveurs où ta clé publique est présente [:cupra]

---------------
Intermittent du GNU

Profil supprimé

Presque fini \o/

initiators

Quelqu'un sait pourquoi on est oblige de faire un aptitude install openssh-client openssh-server?

root@ks01:~ # aptitude upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture de l'information d'état étendu
Initialisation de l'état des paquets... Fait
Lecture des descriptions de tâches... Fait
Construction de la base de données des étiquettes... Fait
Les paquets suivants ont été conservés :
openssh-client openssh-server
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 2 non mis à jour.
Il est nécessaire de télécharger 0o d'archives. Après dépaquetage, 0o seront utilisés.

Message édité par initiators le 15-05-2008 à 09:46:38

e_esprit

Parce qu'ils ont rajouté un paquet openssh-blacklist qui bloquera automatiquement les clefs RSA et DSA listées dans les fichiers /etc/ssh/blacklist_XYZ

=> aptitude update && aptitude dist-upgrade

Message édité par e_esprit le 15-05-2008 à 09:48:14

---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.

Publicité

sligor

aptitude dist-upgrade
parceque ça necessite l'installation d'un nouveau paquet: openssh-blacklist

[:grilled]

Message édité par sligor le 15-05-2008 à 09:49:44

initiators

Je savais pas que le dist-upgrade etait obligatoire des qu'il y avait une nouvelle dependance.

sligor

C'est justement ce qui différencie upgrade et dist-upgrade.
C'est une question de gestion de dépendance, les modifier est plus risqué qu'une simple mise à jour des paquets déjà en place, donc la commande est différente.

Citation :

dist-upgrade
La commande dist-upgrade effectue la fonction upgrade en y ajoutant
une gestion intelligente des changements de dépendances dans les
nouvelles versions des paquets ; apt-get possède un système
« intelligent » de résolution des conflits et il essaye, quand c’est
nécessaire, de mettre à niveau les paquets les plus importants aux
dépens des paquets les moins importants. Le fichier
/etc/apt/sources.list contient une liste de sources où récupérer les
paquets désirés. Voyez aussi apt_preferences(5) pour un mécanisme de
remplacement des paramètres généraux pour certains paquets.

Message édité par sligor le 15-05-2008 à 10:13:35

black_lord

Modérateur
Truth speaks from peacefulness

http://roland.entierement.nu/blog/ [...] shssl.html en français

et http://blog.drinsama.de/erich/en/l [...] h-weakness à lire aussi.

Je ne donne pas le lien vers le registre de clés mais bon : mettez à jour, faites du ménage...

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Hrolf

Ma clef date de tellement longtemps qu'elle est bonne

---------------
Il y a trois sortes de mensonges : les mensonges, les gros mensonges et les statistiques !

multani

Dépressionnisé

Par contre, c'est pas très malin : openssh-* a été mis à jour avec une priorité critical, mais c'est pas encore dans testing parce qu'il y a une dépendance sur openssh-blacklist qui est en priorité low -_-

Message cité 1 fois

gug42

J'essaye de tester les clefs OpenVPN avec l'outil dowk.pl mais ca ne marche pas :

Code :

perl /root/dowkd.pl file <user>.key
<user>.key:1: warning: unparsable line
<user>.key:2: warning: unparsable line
<user>.key:3: warning: unparsable line
<user>.key:4: warning: unparsable line
<user>.key:5: warning: unparsable line
<user>.key:6: warning: unparsable line
<user>.key:7: warning: unparsable line
<user>.key:8: warning: unparsable line
<user>.key:9: warning: unparsable line
<user>.key:10: warning: unparsable line
<user>.key:11: warning: unparsable line
<user>.key:12: warning: unparsable line
<user>.key:13: warning: unparsable line
<user>.key:14: warning: unparsable line
<user>.key:15: warning: unparsable line

Message cité 1 fois
Message édité par gug42 le 15-05-2008 à 13:42:41

Taz

bisounours-codeur

y a quand même un truc qui m'échappe dans tous ça: openssl devrait peut-être patcher leur PRNG pour qu'il ne fonctionne pas s'il n'a pas été initialisé avec assez d'entropie. non ?

Message cité 1 fois

sligor

multani a écrit :

il ny'a rien de critique dans cette maj d'openssh, le bug est dans le paquet openssl.

Message édité par sligor le 15-05-2008 à 12:16:46

franceso

Taz a écrit :

y a quand même un truc qui m'échappe dans tous ça: openssl devrait peut-être patcher leur PRNG pour qu'il ne fonctionne pas s'il n'a pas été initialisé avec assez d'entropie. non ?

+1, mais d'un autre côté je sais pas si c'est facilement détectable.

Message cité 1 fois

---------------
TriScale innov

Hrolf

Bha ça ferait un warning et un dev commenterait la sécurité

Message cité 1 fois

---------------
Il y a trois sortes de mensonges : les mensonges, les gros mensonges et les statistiques !

black_lord

Modérateur
Truth speaks from peacefulness

franceso a écrit :

+1, mais d'un autre côté je sais pas si c'est facilement détectable.

gnupg le fait il me semble

Hrolf a écrit :

Bha ça ferait un warning et un dev commenterait la sécurité

[:tinostar]

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

gug42

gug42 a écrit :

J'essaye de tester les clefs OpenVPN avec l'outil dowk.pl mais ca ne marche pas :

Code :

perl /root/dowkd.pl file <user>.key
<user>.key:1: warning: unparsable line
<user>.key:2: warning: unparsable line
<user>.key:3: warning: unparsable line
<user>.key:4: warning: unparsable line
<user>.key:5: warning: unparsable line
<user>.key:6: warning: unparsable line
<user>.key:7: warning: unparsable line
<user>.key:8: warning: unparsable line
<user>.key:9: warning: unparsable line
<user>.key:10: warning: unparsable line
<user>.key:11: warning: unparsable line
<user>.key:12: warning: unparsable line
<user>.key:13: warning: unparsable line
<user>.key:14: warning: unparsable line
<user>.key:15: warning: unparsable line

ca inspire pas grand monde c'est ca ?

Message cité 1 fois

sligor

C'est bien une clé publique ?

Message cité 1 fois

burn2

Pour ceux qui viendront après

En passant pour faire retomber un peu l'attention et détendre l'atmosphère un peu

La fonction responsable de tous ces malheurs:

Sinon on est sur que ça ne touche que les distribs de debian et ses dérivés??

Message cité 2 fois
Message édité par burn2 le 15-05-2008 à 14:50:29

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

masklinn

í dag viðrar vel til loftárása

burn2 a écrit :

En passant pour faire retomber un peu l'attention et détendre l'atmosphère un peu

La fonction responsable de tous ces malheurs:

http://imgs.xkcd.com/comics/random_number.png

burn2 a écrit :

Sinon on est sur que ça ne touche que les distribs de debian et ses dérivés??

Sauf si les dérivés ont été créés à partir d'une debian plus ancienne que l'arrivée du paquet modifié [:spamafote]

---------------
I mean, true, a cancer will probably destroy its host organism. But what about the cells whose mutations allow them to think outside the box by throwing away the limits imposed by overbearing genetic regulations? Isn't that a good thing?

Nashii89

Debian Powerfull Imagination

gug42 a écrit :

ca inspire pas grand monde c'est ca ?

Même problème

En fait, il faut simplement utiliser cet outil sur tous les fichiers trouvés par "locate .key" ?
Je pense que c'est bon pour mon système sinon, les clés datent de sarge ...
Mais bon, j'ai aussi le problème de "unparsable line"

---------------
Debian Addict - Vista Victim .. - Etudiant Ingénieur [Le Pas-Blog - Relations Ecrites]

gug42

sligor a écrit :

C'est bien une clé publique ?

bah nan c'est les clefs privées

Message cité 1 fois

franceso

burn2 a écrit :

Sinon on est sur que ça ne touche que les distribs de debian et ses dérivés??

En fait les autres distribs sont un peu touchées indirectement : on risque de voir fleurir les attaques par bruteforcing sur les 32000 et quelques clés touchées. Du coup, si un utilisateur d'une autre distrib a par hasard (un vrai hasard cette fois-ci) récupéré une de ces clés, son système est maintenant fortement compromis (ce qui n'est plus le cas pour Debian puisque les clés compromises sont blacklistées)

(cf par exemple http://blog.drinsama.de/erich/en/l [...] -weakness)

Message cité 1 fois

---------------
TriScale innov

burn2

Pour ceux qui viendront après

franceso a écrit :

Effectivement. En gros on perd aussi pas mal de clef générée aléatoirement! :ouch:

Message cité 1 fois

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

Taz

bisounours-codeur

GNOME vient de verrouiller ses serveurs pour le moment.

sligor

burn2 a écrit :

Effectivement. En gros on perd aussi pas mal de clef générée aléatoirement! :ouch:

Non il y a plus de chance de gagner plusieurs fois d'affiler au loto que de générer une clé blacklistée avec un RNG qui n'a pas de faille.

Message cité 1 fois
Message édité par sligor le 15-05-2008 à 16:10:47

Skateinmars

gug42 a écrit :

bah nan c'est les clefs privées

Faut apprendre à lire une aide

---------------
Feedback HAV

franceso

sligor a écrit :

Non il y a plus de chance de gagner plusieurs fois d'affiler au loto que de générer une clé blacklistée avec un RNG qui n'a pas de faille.

T'es sûr de ça ?

Après lecture rapide du code d'openSSL, il semblerait que la graine du RNG soir stockée sur 4 char, ce qui donne un maximum théorique de 2^32 possibilités.
Donc la probabilité de tomber aléatoirement sur une clé blacklistée est de 2^15/2^32 = 2^(-17), soit environ une chance sur 130000. C'est pas énorme, mais au regard du nombre d'utilisateurs d'openSSL, ça ne me parait pas négligeable du tout...

---------------
TriScale innov

Xavier_OM

Monarchiste régicide (fr quoi)

Je pense qu'avec 2^32 graines possibles, tu génères 2^32 séries de nombres. Pour chaque série tu peux faire un certain nombre de tirage avant de boucler et de retomber sur ton point de départ.

Bref 2^32 graines => 2^32 * (nombre de nombres dans une série pseudo aléatoire) nombres aléatoires.

Là pour chaque (type de clef,taille de clef,architecture) on a cramé 32767 clefs. Pas énorme donc.

Message cité 1 fois

---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.

franceso

Xavier_OM a écrit :

Je comprends pas trop l'argument...

2^32 graines (normalement)
=> 2^32 * (nombre de nombres dans une série pseudo aléatoire) nombres aléatoires.

2^15 graines (les pids de processus dans la version biaisée Debian)
=> 2^15 * (nombre de nombres dans une série pseudo aléatoire) nombres aléatoires.

Dans tous les cas le rapport est de 2^(-17). Ou alors j'ai loupé quelque chose :??:

Message cité 2 fois

---------------
TriScale innov

czh

franceso a écrit :

Dans tous les cas le rapport est de 2^(-17). Ou alors j'ai loupé quelque chose :??:

Je crois qu'il s'expriment mal, il faudrait plutôt dire

Citation :

On a cramé 2^32 - 2^15 clefs, il ne nous reste plus que 2^15 clefs possibles. Pas énorme donc.

edit : mauvais edit

Message cité 1 fois
Message édité par czh le 15-05-2008 à 20:27:32

masklinn

í dag viðrar vel til loftárása

czh a écrit :

Je crois qu'il s'expriment mal, il faudrait plutôt dire

Citation :

On a cramé 2^32 - 2^15 clefs, il ne nous reste plus que 2^15 clefs possibles. Pas énorme donc.

Sauf que c'est n'importe quoi, faut que tu retournes en primaire parce que l'arithmétique et toi ça fait 2...

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
2^32
4294967296
2^15
32768
2^32 - 2^15
4294934528

On remarquera que le dernier chiffre n'est pas égal à 2^15 [:dawak]

2^15 clés ont été cramées sur un total de 2^32, ça fait 0.00076% du nombre de total de clés dispos dans le keyspace.

Edit: et ce qui a été cramé, ce sont des seeds pas des keys si je ne m'abuse, même si le rapport reste probablement le même.

Message cité 1 fois
Message édité par masklinn le 15-05-2008 à 20:21:24

czh

masklinn a écrit :

Sauf que c'est n'importe quoi, faut que tu retournes en primaire parce que l'arithmétique et toi ça fait 2...

Non j'ai bien pris en compte les bons chiffres, c'est bien ce que je voulais dire :

Citation :

On a cramé 2^32 - 2^15 clefs, il ne nous reste plus que 2^15 clefs possibles. Pas énorme donc.

<=>

Citation :

On a cramé 4294934528 clefs, il ne nous reste plus que 32768 clefs possibles. Pas énorme donc.

Oui ce sont des seeds, mais les seeds généralement ça donne des suites constantes après, donc clefs possibles = nombre de seed.

Message cité 1 fois
Message édité par czh le 15-05-2008 à 20:34:24

masklinn

í dag viðrar vel til loftárása

czh a écrit :

Non j'ai bien pris en compte les bons chiffres, c'est bien ce que je voulais dire :

Citation :

On a cramé 2^32 - 2^15 clefs, il ne nous reste plus que 2^15 clefs possibles. Pas énorme donc.

<=>

Citation :

On a cramé 4294934528 clefs, il ne nous reste plus que 32768 clefs possibles. Pas énorme donc.

Sauf que c'est l'inverse, si ça avait "cramé" 99.9993% du keyspace on aurait rien cramé du tout [:pingouino]

Message cité 1 fois
Message édité par masklinn le 15-05-2008 à 20:40:49

czh

masklinn a écrit :

Sauf que c'est l'inverse, si ça avait "crâmé" 99.9993% du keyspace on aurait rien cramé du tout [:pingouino]

Il y a donc différents sens du mot crâmé ?

edit : Bon après s'il faut débattre des théorèmes ensemblistes. Chacun comprendra ce qu'il voudra.

edit2 : Si tu crâmes 99.99993% de ta maison, tu conclus quelle n'a pas crâmé du tout ? :??:

Message cité 1 fois
Message édité par czh le 15-05-2008 à 20:44:59

Publicité

Page : 1 2 3 4

Page Suivante

Page Précédente

Haut de page

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 Debian	PXE Ubuntu - Debian
Ubuntu Party [Amiens] 24-25 mai	[ubuntu] problème grub error 18
Debian: config Eth pour wifi	Problème d'install debian
[ubuntu]installer les pilotes pour geforce 6600gt	ubuntu 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/)

Page générée en 0.131 secondes