Only heap is randomized and it's just around 7 bits (some times reported 5, 4, none and at most 8 bits), DLL base randomization only takes place in boot time and it seems to be just incremental in most cases (and affects only core system libraries like kernel32.dll), thus likely predictable:
kernel32.dll: GetTickCount()
774A910E
[reboot]
774F910E
[reboot]
77B6910E
No VirtualProtect() restrictions exist, thus all tests of that category fail. With DEP policy set to OptOut, the basic memory permissions enforcement tests have all positive results.
Looking forward to test the stack randomization and other improvements in post-beta-2. Right now, the results show the effects of a weak implementation, the heap randomization is too low for being considered truly effective and the fact that DLL base randomization is performed on boot time doesn't
help. Basically, this is the same as a Windows XP Service Pack 2 system with DEP policy set to OptOut and hardware support for the NX bit.
Vista Probe reports "No Randomization" for the DLL base test due to the way it's done. It expects the executable to perform runtime randomization of the base address, but this is obviously not the case. It will work fine for both stack and heap randomization, as well as EXE base randomization (if it can be enabled on third-party applications).
A new article by Michael Howard, but still no information available with an in-depth explanation of how ASLR is implemented in Vista:
0 comments:
Post a Comment