Microsoft et les bugs

Au hasard de mes peregrinations au sein de Windows j'ai ete confronte a une situation qui m'a laisse songeur. N'ayant pas tous les elements en main, si quelqu'un en sait davantage, n'hesitez pas a me corriger.

Dans des extensions FrontPage pour IIS 6, se trouve un morceau de code parsant les images GIF. Jusque la rien d'extraordinaire. Un rapide coup d'oeil aux symboles et l'on trouve les fonctions suivantes:

• VgdImageGifDecoder::Decode
• ReadOK
• VgdImageGifDecoder::LWZReadByte
• VgdImageGifDecoder::ReadColorMap
• VgdImageGifDecoder::DoExtension
• etc.

Un peu de Googling m'apprendra que LWZReadByte() est aussi present dans libgd et SDL_image. Au vu du nom des fonctions, on pourra supposer que Microsoft a pris le code de libgd pour decoder ses GIF. L'analyze du code assembleur revele du moins que les codes ont une source similaire.

Toujours est-il qu'une vulnerabilite a ete decouverte dans LWZReadByte il y a un moment, et a touche aussi bien libgd que SDL_image:

• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4484 pour libgd
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6697 pour SDL_image
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1373 pour un bug similaire dans CUPS, bien que la fonction ne soit pas la meme

Le code original semble provenir de 1990 par un certain David Koblas, mais je n'ai pas trouve de signalement du bug datant d'avant 2006.

Maintenant, regardons le code present dans Windows 2003 SP0 (sorti le 24 Avril 2003 d'apres Wikipedia):

.text:32E274FF ; private: int __thiscall VgdImageGifDecoder::LWZReadByte(class Vistream *, int, int) .text:32E274FF ?LWZReadByte@VgdImageGifDecoder@@AAEHPAVVistream@@HH@Z proc near .text:32E274FF ; CODE XREF: VgdImageGifDecoder::ReadImage(VgdImage *,Vistream *,int,int,uchar (*)[256],int,int)+8Ep .text:32E274FF ; VgdImageGifDecoder::ReadImage(VgdImage *,Vistream *,int,int,uchar (*)[256],int,int):loc_32E278F2p ... .text:32E274FF .text:32E274FF var_104 = byte ptr -104h .text:32E274FF arg_0 = dword ptr 8 .text:32E274FF arg_4 = dword ptr 0Ch .text:32E274FF arg_8 = dword ptr 10h .text:32E274FF .text:32E274FF push ebp .text:32E27500 mov ebp, esp .text:32E27502 sub esp, 104h .text:32E27508 push ebx .text:32E27509 xor ebx, ebx .text:32E2750B cmp [ebp+arg_4], ebx .text:32E2750E push esi .text:32E2750F push edi .text:32E27510 mov esi, ecx .text:32E27512 jz loc_32E275CE .text:32E27518 mov ecx, [ebp+arg_8] .text:32E2751B cmp ecx, 0Ch .text:32E2751E jg loc_32E2782B

On voit ici que le 3e argument de la fonction est bien compare a MAX_LWZ_BITS (12), et si la taille du code est superieure, on sort. Donc Microsoft etait au courant de ce bug au minimum 3 ans avant qu'il ne soit corrige dans les bibliotheques publiques - et bien entendu la vulnerabilite n'a pas ete reporte par Microsoft. Notez que je ne blame personne, je me contente de constater :) Responsible Disclosure, tout ca.

Encore une fois je ne dispose pas de tous les elements, donc si quelqu'un a quelque chose a ajouter, feel free!

Et pour finir une entree marrante d'un blog de Microsoft qui n'a rien a voir avec le sujet precedent:

http://blogs.msdn.com/david_leblanc/archive/2010/04/16/don-t-use-office-rc4-encryption-really-just-don-t-do-it.aspx

EDIT: le fix est aussi present dans FP4 pour Windows 2000, donc les 3ans se transforment d'un coup en beaucoup plus.

FIRST Conference 2010: In Miami, Bitch

La 22e conference du FIRST se deroulera du 13 au 18 Juin 2010 a Miami. Le programme est disponible ici. Je n'ai pas trop prete attention au deroulement de ces conferences depuis que j'ai quitte le "milieu", mais bon cette annee c'est special vu que ca se deroule pas loin de mon WHQ - et Dave presentera une keynote! Je serai dans les environs, histoire de dire bonjour aux anciennes connaissances - ou me faire cracher dessus.

Si vous comptez vous deplacer pour l'occasion, qu'il n'y a pas de gros nuage volcanique, etc., envoyez moi un mail et je tacherai de vous faire decouvrir Miami et Miami Beach!

Ultra Music Festival 2010

Gros line-up comme d'habitude pour l'UMF cette annee. Miami va etre relativement penible a vivre pendant la semaine de la Winter Music Conference, mais bon on va tacher de faire avec.

Barbouzeries

27 minutes qui valent le detour.

Un peu d'humour

Vu que je n'ai rien d'autre a poster:

Heap Overflows a Miami en Janvier

Pas de mise a jour ces derniers temps, il ne se passe pas grand chose.

Debut Janvier aura lieu a Miami Beach un training sur les Heap Overflows organise par Immunity. D'habitude je ne parle pas de ce genre de choses sur ce blog, si ce n'est que ce coup-ci, deux francais seront aux commandes: Nicolas Pouvesle et moi-meme. Le training sera donne en Anglais (vu que les participants deja inscrits sont anglophones), mais peut etre que certains lecteurs de ce blog trouveront un interet a avoir des "trainers" francophones. L'autre avantage sera bien evidemment de passer une semaine a Miami Beach a une periode de l'annee ou il fait plutot froid ailleurs :)

Pour plus de details sur le training, contactez admin a immunityinc point com.

L'honneur est sauf!

Comme certains d'entre vous auront pu s'apercevoir, une technique d'exploitation du bug SMBv2 a ete publiee sur le blog de Metasploit par Piotr Bania (qui ne travaille pas pour Immunity comme pourraient le penser certaines personnes mal informees - cf. FLS). Et elle se revele plus fiable que la precedente de Stephen Fewer (qui ne marchait jamais).

Donc l'honneur est sauf! Je ne serai pas a l'origine de la nouvelle apocalypse numerique, comme le prophetisait certains, et je pourrai dormir paisiblement pendant que les jeunots pirateront des honeypots avec l'exploit Metasploit.

Quelques precisions/pensees sur le bug SMBv2:

• Malgre tout le buzz qui en a ete fait (y compris par Immunity), je trouve que le bug au final n'est que peu interessant, pour la simple raison qu'il n'est exploitable que sur plateformes x86.
• Si vous avez du x64, vous etes tranquille (pour le moment, mais ca ne devrait pas changer - sauf intervention divine), parceque les parametres de la fonction sont passes par registres et non par la pile, ce qui rend la technique de stack shifting inutilisable. Du 2008 x86 c'est super rare (3GB de memoire sur un serveur en 2009 c'est pas super utile), et du Vista x86, meme si c'est plus repandu, ca reste tout de meme rare (cf. pentests recents que j'ai pu mener).
  
• Comme d'habitude, pas grand monde n'a compris ce qui se passait, c'est pas nouveau, la securite informatique ce n'est pas un succes. Si vous avez des problemes de comprehension, evitez de l'ouvrir, vous passerez pour plus stupide que vous ne l'etes.
• Il est dommage de constater que l'exploitation d'un bug de nos jours est si problematique. Il aura fallu ~3 semaines a Stephen Fewer pour creer un exploit qui ne fonctionne pas souvent (a cause de l'adresse choisie dans le Bios/HAL), et ~1 mois a Piotr Bania pour arriver a quelque chose de fonctionnel grace, semble-t-il, a l'exploit publie precedemment. Beau boulot neanmoins des 2, puisque le resultat est la!

C'est beau Internet.