"Exploitability Index" ou comment perdre son (mon) temps

Depuis quelques mois deja, Microsoft a rajoute un "Exploitability Index" a ses bulletins mensuels. Cet indice d'exploitabilite est decrit sur cette page. Il consiste en un simple chiffre:

1. Consistent exploit code likely
2. Inconsistent exploit code likely
3. Functionning exploit code unlikely

Le modele a fait l'objet d'un papier du sieur Bas Alberts (disponible ici). Et les gens de Microsoft se plantent rarement dans leur analyse. Un post du "Silver Surfer" Mike Reavey couvre le sujet en analysant un mois de bulletins et d'exploits.

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

Les "Certifications"

Aujourd'hui je recois un mail d'un mec qui veut des informations a propos de VMware. La personne en question est CISSP, SANS GCIA, MCSE, CCSA, CCSE, CSA, CCNA, et CNA. Ca fait beaucoup. Les questions sont: Et votre exploit il fait quoi??? Et ca marche sous ESX???

Donc apparemment plus avez de certifications, moins vous savez utiliser Google. Et ca semble diminuer d'autant votre comprehension de l'Univers aussi. Et les questions (ou leurs reponses pour etre exactes) sont destinees a etre ajoutees a des slides pour une presentation ayant lieu dans 2 semaines a une grosse conference.

C'est pas mal de decouvrir ce qui se passe deux semaine avant. Ca doit etre ce qu'on appelle la veille.

MOSDEF over Direct3D

Des fois, je fais des trucs a la con.

Un example est quelque chose sur lequel je bosse un peu en ce moment: MOSDEF Over Direct3D. C'est le genre de trucs qui va m'etre utile une seule fois, mais dont le concept est intellectuellement stimulant. Le seul interet de MOSDEF Over Direct3D: le bug VMware. Ou comment s'assurer du maintient d'un canal de communication entre l'Hote et l'Invite sans se fier a des fonctionalites pouvant etre absentes (reseau) ou desactivees (vmrpc, vmci, etc).

La solution: etablir un canal de communication via le Frame Buffer de l'Invite. Dans la mesure ou le Frame Buffer est sense etre 'abstrait' par les multiples couches graphiques de Windows, il n'est pas evident de pouvoir y acceder directement en Ring 3. Sauf via DirectX/Direct3D.

Le jeu est donc d'ecrire un proxy TCP (MOSDEF se fonde sur du TCP de base) vers Direct3D pour l'Invite, puis du cote de l'Hote: lecture et execution du code et reecriture du resultats dans le Frame Buffer (facile).

C'est bien de se faire plaisir de temps en temps. Le tout devrait faire l'objet d'une presentation si je suis accepte a Vegas.

Sans le SANS ...

... que ferait-on? Ils ont decide de se reveiller ce matin pour une raison que j'ignore:
VMware exploits - just how bad is it ?

Pas mal les mecs. Il leur a fallu 2 semaines pour realiser ce qui se passait. Et dire qu'ils sont senses representer une sorte d'elite de la securite, toujours au courant de ce qui se passe, etc.

Edit: Au passage, un CVSS de 10! (NIST)

La bonne nouvelle c'est qu'Ulduar, la nouvelle instance de Raid de WotLK sort aujourd'hui. On va enfin pouvoir faire autre chose!

HP NetTop

Page Wikipedia:
http://en.wikipedia.org/wiki/NetTop

Le document "technique":
http://h71028.www7.hp.com/enterprise/downloads/HP_NetTop_Whitepaper2.pdf

Le "Virtual Air Gap" (c) HP:

Allez, pour bien commencer le Samedi

Tire du Blog de VMware Fusion:
http://blogs.vmware.com/teamfusion/2009/04/vmware-fusion-204-update-now-available.html

"2.0.4 already?", you ask. That's right, we are releasing VMware Fusion 2.0.4 today to address a critical security issue. At VMware, we take security very seriously and always stay vigilant to provide the safest products and solutions possible.

Maintenant, on sait que CLOUDBURST a ete fixe en silence avec VMSA-2009-0005 (dans Workstation du moins), puis annonce avec VMSA-2009-0006. Question: quel produit est specifie non affecte dans 0005, et patche une semaine plus tard avec 0006?

Quelque part ca suit la politique de l'OS sur lequel ca tourne.

CVE-2009-1244

Il semblerait qu'apres une tentative de patch silencieux de la part de vous-savez-qui, CLOUDBURST se soit vu assigner un CVE:

http://lists.vmware.com/pipermail/security-announce/2009/000055.html

"A critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host."

J'aime bien le "might". Heureusement qu'on est Vendredi.