Bonne analyse de cette vulnérabilité. Comme tu sais je suis fan de tout ce qui est exploitation surtout quand ça concerne un contexte comme le kernel. Une bonne introduction a l’exploitation des NULL défèrence dans le kernel.
PVOID AllocateAddr=(PVOID)1; C’est pour dire que AllocateAddr est egal à 1 tout simplement, puisque si on met une valeur de mémoire nulle à ZwAllocateVirtualMemory il aime pas (à vérifier pourquoi), donc on met 1 et du fait de la granularité des pages on alloue la page 0. La valeur 0×200 est complètement arbitraire.
Après je copie le shellcode en 0×200 avec un memcpy. Je place ensuite à l’adresse 0+0xD*4+0×38 un pointeur sur le shellcode donc 0×200 parce que le code va confondre la structure qui commence en 0 avec une structure DRIVER_OBJECT qui contient en 0×38 un tableau de pointeurs de fonctions sur les handlers d’IRP. C’est ainsi que le driver buggé va utiliser ce pointeur pour appeler le handler et donc notre shellcode …
C’est plus clair j’espère ?
6.
rootkited | juillet 2nd, 2008 at 12:06
merci pour l’explication.
« on met 1 et du fait de la granularité des pages on alloue la page 0. La valeur 0×200 est complètement arbitraire. »
ca m’a bien aidé.
et juste pour remarque ce serait bien que tu trouves un moyen de mettre en evidence la ou les ligne(s) importante(s) dans le listing (debuggeur) de kd ca permet au lecteur de se focaliser sur les points importants.
6 Comments
1. mxatone | février 28th, 2008 at 22:22
Bonne analyse de cette vulnérabilité. Comme tu sais je suis fan de tout ce qui est exploitation surtout quand ça concerne un contexte comme le kernel. Une bonne introduction a l’exploitation des NULL défèrence dans le kernel.
Ne sous estimez pas les NULL deference :
Microsoft Windows Vista Local Privilege Escalation Vulnerability (MS07-066):
http://www.microsoft.com/technet/security/bulletin/MS07-066.mspx
Une erreur suffit !
2. wo | février 28th, 2008 at 22:59
Superbe intro pour moi à ce type de faille que je ne connaissais pas.
nj as usual
3. Ruben | mars 6th, 2008 at 16:13
Neat analysis
4. rootkited | juillet 2nd, 2008 at 01:47
dsl d’avoir remonté le topic.
merci pour ce demo
mais j’ai quelques questions si vous me permettez ?
dans le code source (l’exploit)
PVOID AllocateAddr=(PVOID)1;
0×200; pointe à l’adresse mémoire 1 ?
l’autre probléme c’est celui la. t’es sur que c’est du language c (lol).
//somewhere in nowhere …
((PULONG)0)[0xD*4+0x38]=0×200;
voulez bien expliquez cette ligne ?
pkoi (PULONG)0 ?
alors que AllocateAddr débute à l’adresse mémoire 1.
ensuite appliqué au [0xD*4+0x38] ?
et égale 0×200 ? pkoi
j’ai passé pas mal de temps à l’interpréter mais je pige keudale.
thanks
5. admin | juillet 2nd, 2008 at 10:43
PVOID AllocateAddr=(PVOID)1; C’est pour dire que AllocateAddr est egal à 1 tout simplement, puisque si on met une valeur de mémoire nulle à ZwAllocateVirtualMemory il aime pas (à vérifier pourquoi), donc on met 1 et du fait de la granularité des pages on alloue la page 0. La valeur 0×200 est complètement arbitraire.
Après je copie le shellcode en 0×200 avec un memcpy. Je place ensuite à l’adresse 0+0xD*4+0×38 un pointeur sur le shellcode donc 0×200 parce que le code va confondre la structure qui commence en 0 avec une structure DRIVER_OBJECT qui contient en 0×38 un tableau de pointeurs de fonctions sur les handlers d’IRP. C’est ainsi que le driver buggé va utiliser ce pointeur pour appeler le handler et donc notre shellcode …
C’est plus clair j’espère ?
6. rootkited | juillet 2nd, 2008 at 12:06
merci pour l’explication.
« on met 1 et du fait de la granularité des pages on alloue la page 0. La valeur 0×200 est complètement arbitraire. »
ca m’a bien aidé.
et juste pour remarque ce serait bien que tu trouves un moyen de mettre en evidence la ou les ligne(s) importante(s) dans le listing (debuggeur) de kd ca permet au lecteur de se focaliser sur les points importants.
thanks for this great work.
Trackback this post