Great post! Re: the spraying technique used, since Windows 8, 64-bit apps that optin to high entropy ASLR (like Chrome) have ~2TB of variance in where bottom up allocations start from, hence why there is a need to spray so much (3.5TB mentioned in the blog)https://twitter.com/benhawkes/status/1116405223986089984 …
-
Show this thread
-
Re: DLLs being located at the same base addr between processes, there is a long history here. ASLR support in Windows tries to maximize sharing of pages for DLLs. Using the same base reduces the likelihood of base address collisions (which result in COW costs due to relocs). 1/n
2 replies 4 retweets 14 likesShow this thread -
There are also assumptions made by various parts of Windows (and apps that run on Windows) that DLLs are located at the same address cross-process. While engineering can change the former, the latter are harder to deal with and create app compact problems 2/n
2 replies 0 retweets 5 likesShow this thread -
ASLR support was initially added in Windows Vista when 32-bit x86 DLLs were common. Since 32-bit x86 doesn’t have RIP relative addressing, relocs are much more common. Nowadays, 64-bit DLLs have become the norm and they tend to have far fewer (but non zero) relocs. 3/n
1 reply 0 retweets 6 likesShow this thread -
There has actually been some behind-the-scenes work in the MSVC linker over the years to minimize the number of pages with relocs (e.g. by merging relocs onto the fewest # of pages possible), but even still it is uncommon to have no relocs. 4/
1 reply 0 retweets 7 likesShow this thread -
That all being said, randomizing to different base addresses between processes has been evaluated at various points in the past and the engineering scales didn’t balance, but as with most things it’s good to keep an open mind and consider new data
5/n3 replies 0 retweets 14 likesShow this thread -
Last tid bit: WehnTrust (ASLR for XP) supported the concept of “image sets” and could randomize DLLs to diff base addresses in each image set (eg one for admin, one for nonadmin). It was an ultra hack that no one should recreate, but it mostly worked. https://archive.codeplex.com/?p=wehntrust 6/6
3 replies 1 retweet 14 likesShow this thread -
This Tweet is unavailable.
It's from the unfortunately-named company that made WehnTrust: Wehnus. https://web.archive.org/web/20050315001908/http://www.wehnus.com/ …
-
This Tweet is unavailable.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.