Lees het eens goed, het komt erop neer dat je via een applicatie met administrator rechten (in zijn voorbeeld een virusscanner), de security omzeilt. Het probleem is dus niet zozeer een windows probleem alswel dat bepaalde windows applicaties niet secure zijn.
Nee, lees jij het eens eens goed
Het probleem van het Windows message systeem is dat ieder window een message kan sturen naar ieder ander window, en dat het ontvangende window niet kan controleren waar de message vandaan kwam (!). Daar komt nog bij dat sommige messages bijzonder lompe dingen kunnen doen zonder medeweten of tussenkomst van het doel-window.
Uit de tekst:
Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. Silly, silly, silly...
Dus je kunt een window van een andere applicatie een WM_TIMER message sturen, en dan gaat die ontvangende applicatie code uitvoeren op het adres dat jij aanwijst! En dat - voorzover de schrijver weet - zonder dat het doel-window dat kan weigeren.
Dat is gewoon lomp. En misschien zijn er wel manieren om daaromheen te komen (mogelijk ten koste van bepaalde functionaliteit), maar als het standaard zo makkelijk is om een andere applicatie te beinvloeden, dan is dat een probleem van Windows, niet van de applicaties.
Dat wil ik overigens wel even veralgemeniseren, want dat geldt voor andere situaties net zo goed:
Als een platform zo in elkaar zit dat applicaties voor fatsoenlijke security om het platform heen moeten werken, dan is dat een probleem van het platform, en niet van de applicaties die er niet omheen werken.Vergelijkbare problemen zouden ook onder *nix kunnen voordoen, als een applicatie onder Root Rechten draait, en kan communiceren met een "user", zou als het programma niet goed in elkaar zit, ook misbruik kunnen worden gemaakt.
Ja, maar dan gaat het specifiek om fouten in de applicatie.
Een goed voorbeeld is XFree86, de meest gebruikte X server op Free OSsen. XFree86 draait als root. Alle X applicaties (die doorgaans als een gewone user draaien) moeten met de X server comminuceren. Als er in de X server een fout zit waardoor een X client meer kan dan hij zou moeten kunnen, dan is dat een security probleem. Van XFree86 wel te verstaan.
Maar de standaard API die door de Linux kernel wordt aangeboden (voornamelijk POSIX plus wat misc. UNIX98 en BSD spul) maakt het niet mogelijk voor user processes om enige invloed op XFree86 uit te oefenen als XFree86 daar niet mee accoord gaat.
En daar zit het grote probleem met MS Windows' messages: windows kunnen een (te) grote invloed uitoefenen op andere windows zonder dat het doelwindow daar om vraagt of mee accoord gaat.
Daarnaast is het zo, dat het op windows machines niet erg gebruikelijk is om andere mensen zomaar visueel toegang te geven (zeker niet op servers).
Nou... Op desktops en workstations dus juist wel he
Wat betreft servers heb je gelijk, daar zal dit gebrek niet zo snel problemen opleveren, maar het is en blijft een fundamenteel win32 probleem.
Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
/i/1248090062.png?f=fpa)
/u/90866/pinguin.png?f=community){kind=small}
).
:strip_icc():strip_exif()/u/68401/crop621367cd595e0_cropped.jpg?f=community){kind=small}
maar niet zomaar. Je moet er wel wat voor doen om jouw code in een project te krijgen hoor. Over closed-source worden er ook nuttige opmerkingen gemaakt:
:strip_icc():strip_exif()/u/40949/polarwolf.jpg?f=community){kind=small}
/u/26742/000000751.png?f=community){kind=small}
) maar het voorkomt wel dat oude en al opgeloste problemen zich blijven voordoen./u/35152/avaoxi-60x60.png?f=community){kind=small}
:strip_icc():strip_exif()/u/28529/Pelle.jpg?f=community){kind=small}
/u/2216/got_avatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/78771/sluuut.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/51090/tentacle.jpg?f=community){kind=small}
:strip_exif()/u/35573/0sm.gif?f=community){kind=small}
Maar, bekijk ook de trolls in deze reactielijst (laagste niveau), en de reacties daarop die gemod zijn met inzichtvol. 
/u/62799/crop589e049deeb18_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/10361/nylon_beat.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/43619/crop67c6cc2ef27d8_cropped.jpg?f=community){kind=small}
:strip_exif()/u/23403/wicky55.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/75371/airtimeSmall.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community){kind=small}