Re:RIP ROP: CET Internals in Windows 20H1
by saagarjha on Tuesday July 21, 2020 @11:18PM
(#23913590)
It's kind of easy to say "ASLR is not resistant to infoleaks" but it's really quite another thing if the infoleak ends up coming from something like a microarchitectural sidechannel or even an undocumented proprietary processor extension, rather than "hurr durr here is a slid pointer, we hand out these out like candy".
[ Parent
| on HN ]
Re:RIP ROP: CET Internals in Windows 20H1
by staticassertion on Wednesday July 22, 2020 @01:11AM
(#23914127)
My point is that ASLR makes assumptions about the attackers capabilities. All good mitigations do. If the attacker has "I can run nearly arbitrary computations on within the processes memory space", that is outside of the model that ASLR attempts to deal with.
For example, ASLR for a process that executes Javascript is probably not going to be as useful as ASLR for a process that receives network requests.
Re:RIP ROP: CET Internals in Windows 20H1
by saagarjha on Wednesday July 22, 2020 @01:55AM
(#23914314)
How so? As far as I understand, being able to leak an ASLR slide from JavaScript is considered to be a security bug in every browser engine, because they do not intentionally provide access to that information.
Re:RIP ROP: CET Internals in Windows 20H1
by staticassertion on Wednesday July 22, 2020 @08:52AM
(#23916367)
Whether the browser intends to provide that information or not, ASLR was not designed as a control against an attacker who can run near arbitrary code in the process.