- Consistent exploit code likely
- Inconsistent exploit code likely
- Functionning exploit code unlikely
Somme toute, il s'agit d'une bonne metrique si vous voulez prioriser un patch lors d'un Microsoft Tuesday, soit en tant qu'administrateur soucieux de securiser votre reseau, soit en tant que "differ" soucieux d'avoir un exploit fonctionnel au plus vite.
La ou le bat blaisse pour moi, c'est quand Microsoft se plante. L'erreur n'est pas dans la sous evaluation du risque, mais dans la surevaluation.
Prenons l'example du Microsoft Tuesday de Juin 2009. Plusieures failles interessantes (comprenez anonymes distantes), dont MS09-018 et MS09-022.
Le second bulletin, ciblant le service Spooler a ete boucle en moins de deux heures pour la version 2000 (XP n'est que local d'apres le bulletin).
Le premier touche Active Directory, comprend 2 failles, un free() invalide et une fuite de memoire. Un free() d'un pointeur sous votre controle, c'est exploitable sous Windows. Et l'indice d'exploitabilite pour cette faille etait de 1 (cf. blog du MSRC). Donc Toto se met au boulot histoire de voir de quoi il retourne. Apres quelques heures de lecture intensive de lignes d'assembleur et d'envoi de paquets LDAP, il annonce "Je ne vois pas comment ca peut etre exploitable ...". Je regarde, pas mieux.
La primitive du bug est un free(pointeur+X) avec 1<=X<=6, et le pointeur est fixe pointant sur des donnees sous votre controle. Un tel bug pourrait etre exploitable si X=8, 16 ou 24, etc. Par contre si (pointeur+X)&7!=0, RtlFreeHeap() vous envoie chier joyeusement et rien ne se passe. Pourquoi cet indice d'exploitabilite de 1?? C'est rageant, on continue a bosser dessus en pensant qu'on a rate quelque chose. Et puis aujourd'hui, on voit sur le bulletin:
V1.1 (June 10, 2009): Corrected the rating and key notes for CVE-2009-1138 in the Exploitability Index.Alors la. L'indice de 1 est passe a 3, et une petite ligne a ete ajoutee:
However, due to additional checks on the heap, a functioning remote code execution exploit is very unlikely.C'est moche :( Resultat je ne vais plus faire trop confiance a leur "Exploitability Index"...
Edit: extrait du bulletin iDefense:
06/05/2009 - Microsoft informs iDefense that the Bulletin was promoted
to potential Code Execution
06/08/2009 - iDefense requests clarification, offers further insight
06/10/2009 - iDefense reiterates request
06/10/2009 - MS Responds that they agree that code execution is very
unlikely and will change the Exploitability Index
06/11/2009 - MS Changes Exploitability Index from 1 to 3
06/11/2009 - Coordinated public disclosure
3 comments:
I agree that the exploitability index can be misleading. I haven't noticed them changing the index too often, but I've found it's usefulness to be questionable at best.
I think the real problem isn't the scoring of exploitability, but rather the way vulnerabilities are communicated. First you get the extremely vague pre-release. That's followed by the release, and generally ZDI, iDefense, whoever, posting a slightly more detailed release. Each is progressively more informative. I understand that they don't want people to immediately start exploiting the bug but most organizations are lucky to complete patch cycles in a few weeks. The vaguery only gives them a day or two and greatly adds to the poor understanding of vulnerabilities. That furthers the production of poor software and poor IDS signatures.
IMO just another case of security through obscurity wreaking havoc.
"là ou le bât blesse", le machin en bois que l'on met sur le dos des ânes, pas le truc qui nécessite l'usage bien tempéré du porte-jarretelle. D’un coté le bât Canevas, de l’autre le bas résille.. tout un programme.
Et oui c'est ce qui arrive quand on ne parle plus/ecrit plus/lit plus de Francais ...
Post a Comment