Varnost v Visti: igra končana?

Ja, sam sedmica na lotu je relativno pogosta. Le dobitnik je vedno drugi :) [...]

Very true. Lepa primerjava. :)

Še dobro da heap protection mehanizme upravlja kernel :)

Sej se ne spoznam na Winse, ampak na UNIX-u je tako, da kernel ponavadi vraca
vecji chunk pomnilnika, libc pa je potem zadolzen za to, da pohandla vsak
posamezen malloc() / free() in po potrebi zahteva (se) vec pomnilnika.
Za lazje dodajanje in sproscanje kosov pomnilnika ima vse skupaj organizirano
v neko podatkovno strukturo (seznam, drevo, ...) in ti dejansko ko prepises
nekaj na kopici, prepises te interne kontrolne podatke od libcja. Torej
kernel tu ne skrbi za nikakrsno zascito.

Pri Oknih je vse skupaj afaik malo bolj zakomplicirano (kot ponavadi) in imas
vec "heapov", ampak v konci fazi je najbrz podobno.

Najboljša rešitev za 2K/XP/2K3 je verjetno WehnTrust

Zanimiva stvar, bom malo pogledal.

Zakaj tega ne bi počel kernel? Očitno sem napak predvideval, da je SEH protection nemogoče implementirati v kernel.

Nic ni nemogoce, vprasanje je le kako smotrno je.

Ta resitev pri WehnTrust izgleda kar kul - hookajo ntdll!KiUserExceptionDispatcher, ki se itak najbrz poklice v kontekstu jedra in se sprehodijo cez povezan seznam exception handlerjev ter gledajo ce na koncu najdejo svoj dummy handler, ki so ga na zacetku izvajanja dodali (tako se tisti Next obnasa kot neka canary vrednost). /SafeSEH je grsi.

Implementacija stack cookija z nekim preverjanjem v jedru po drugi strani (ceprav se ubistvu slisi podobno) bi bil totalen overkill, saj pri klicu RET ni potrebna ponavadi nobena intervencija s strani jedra.