4 ms·
We've been through several generations of exploit mitigations starting with non-executable stacks, and, impressively, exploit developers found workarounds for e
by schoen 6y ago
We've been through several generations of exploit mitigations starting with non-executable stacks, and, impressively, exploit developers found workarounds for each of them (although often the particular workarounds have requirements that might not be met in a particular vulnerability environment). In many cases I had the impression that the workarounds were surprising to the mitigation developers because the latter had expressed a lot of confidence that software security was about to make a huge leap and memory safety violations would rarely be exploitable anymore.
What are the prospects for finding workarounds to CET too?
(I don't mean to argue that there's no benefit to these mitigations or that some of them might not eventually finally stop whole classes of vulnerabilities. But I feel like their track record is not nearly as awesome as their inventors anticipated, so I wonder what informed opinion is on the eventual relevance or irrelevance of this one. Notably, the "RIP ROP" seems like a somewhat ambitious claim to mitigate a large amount of attack potential; how well-justified is it?)
- muricula 6y agoThere will probably be defeats and accidental gadgets for the first couple releases, but this hardware technology has the potential to be better than any software based mitigation with the same goals. Here's a paper with a more detailed security analysis: https://sci-hub.tw/10.1145/3337167.3337175 https://sci-hub.tw/10.1145/3337167.3337175
- staticassertion 6y agoIt's not totally true that attackers have found ways bypass mitigations. In many cases the attackers require entirely new capabilities, or separate vulnerabilities, to get around a mitigation. And in some cases it makes an attack statistically unlikely, even if it may succeed. Lots of mitigations do suck, and are a huge waste of time and effort, but quite a few are very significant. It's very rare that a bypass is a surprised except when the mitigation is poorly thought out. Good mitigations start with a threat model. An example is ASLR. Once in a while ASLR is pronounced 'dead' because an attacker with capabilities that ASLR does not try to defend against can bypass ASLR. For example, the attacker has arbitrary compute on the system with ASLR. No one who built ASLR was surprised by this.
- saagarjha 6y agoIt'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".
- staticassertion 6y agoMy 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.
- saagarjha 6y agoHow 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.
- staticassertion 6y agoWhether 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.
- pabs3 6y agogrsec seems to think CET won't be effective: https://grsecurity.net/effectiveness_of_intel_cet_against_code_reuse_attacks https://grsecurity.net/effectiveness_of_intel_cet_against_co...
- mjg59 6y agoMost of the negative commentary us around the protection of the forward edges, while this blog is about the backward edges. The grsec post notes that implementing full support for the backward edges involves handling a number of special cases, but doesn't criticise its effectiveness if that work is done.
- pjmlp 6y agoIncredible how C and C++ have managed to keep the security industry busy. Not that other languages don't have logical errors that might lead to security exploits, but in what concerns memory corruption exploits, the mitigation list just keeps pilling up. Looking forward to how long ARM hardware memory tagging will hold on, after Intel's MPX failure. At least so far Solaris SPARC ADI seems to hold on.