Een aantal technische aannames van Steve zijn onjuist, uit
http://www.grc.com/sn/SN-022.htm op dit moment:
> Steve: Yeah. Basically you're giving Windows a pointer.
> You're giving Windows a pointer to a subroutine in
> your code and telling Windows, if the user aborts the
> print job, and I've given you a pointer, then call that
> subroutine of mine, which is a way for Windows to
> notify the application.
Zo werkt het niet. Je vertelt aan windows waar jouw functie
staat, en die wordt vervolgens door windows onder
verschillende omstandigheden aangeroepen, o.a. aan het begin
van "de pagina". Het is
jouw functie die de het
printproces kan afbreken door 0 terug te geven. Dat is de
reden dat exploit-code meteen werkt en niet pas als er een
fout optreedt.
Deze aanpak stamt uit de Windows 3.x tijd. Toen was er geen
echte multitasking tussen applicaties, Program Manager en
Print Manager (wel bijv. in de netwerklaag). Als de disk vol
liep met een pagina die nog niet geheel naar de printer
geflushed was, werd jouw functie aangeroepen. Je kon daarin
dan "wachten" tot die pagina wel geflushed was, en er dus
weer ruimte op de schijf vrijkwam voor de volgende pagina.
Tijdens dat wachten moest je wel vanuit jouw "AbortProc"
routine met bijv. PeekMessage windows de kans geven om het
printen uit te voeren. Info:
http://msdn.microsoft.com/archive/en-us/dnargdi/html/msdn_print.asphttp://the.wall.riscom.net/books/win/petzbook/PART4_15.TXT> Steve: Yeah. Yeah. So I asked myself, isn't there, like,
> a constructive purpose for putting code in a metafile?
> And the problem is, code running in the metafile
> doesn't have access to the context of the metafile.
Ik heb het niet getest, maar volgens de WinAPI van AbortProc
(en de oude Escape SETABORTPROC) krijg je wel degelijk een
HDC parameter via de stack, maar die wordt zelden gebruikt.
Zie de voorbeelden in bovenstaande URL's van Mircosoft en
het tekst uit een boek van Charles Petzold.
Verder wordt er op FD op gewezen dat WINE ook kwetsbaar is:
http://lists.grok.org.uk/pipermail/full-disclosure/2006-January/041384.htmlIk geloof niet in een bewuste backdoor. Wel ga ik er van uit
dat Microsoft geweten moet hebben van dit "lek" en het
bewust niet gepatched heeft. Wellicht omdat er printer
drivers (mogelijk door Microsoft bij Windows meegeleverde)
in omloop zijn die hier gebruik van maken. Ik heb geen
referenties gevonden naar het opslaan van code in metafiles;
ik sluit niet uit dat die mogelijkheid pas met de opkomst
van GDI printers is gerealiseerd en dus helemaal niet zo oud
is (in dat geval zal er andere functionaliteit achter
schuilen dan de afhandeling van volle schijven, want die
zijn tegenwoordig ietsje groter dan in de Win 3.x tijd).
Na eerdere kwetsbaarheden (die ik hieronder noem) kan ik me
niet voorstellen dat de lekken van eind december en begin
januari niet gevonden zijn door Microsoft medewerkers.
Oftewel, er is bewust niet gezocht, of er mocht niet
gepatched worden.
Het is al eerder gebeurd dat shimgvw.dll de schuld kreeg van
een metafile probleem in GDI:
"Microsoft Windows XP Windows shell shimgvw.dll buffer
overflow", gepatched door MS04-011:
http://xforce.iss.net/xforce/xfdb/15284Waar het wel aan lag (en het duurde 164 dagen voordat deze
gepatched was, irresponsible disclosure gaat een stuk sneller):
http://www.eeye.com/html/Research/Advisories/AD20040413F.htmlhttp://www.microsoft.com/technet/security/bulletin/MS05-053.mspxpatchte nog eens twee metafile problemen. Beide waren door
third parties aangekaart.
Erik van Straten