4 ms·
As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to
by lovelearning 7y ago
As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to untrustworthy data which may have propagated down the call chain. Are there no initiatives being attempted to change this convention? Like not save the IP on the stack? Perhaps at the CPU architecture level or at the compiler level?
- Karliss 7y agoThere is SafeStack https://clang.llvm.org/docs/SafeStack.html https://clang.llvm.org/docs/SafeStack.html which splits stack in to two parts.
- deleted 7y ago[deleted]
- lawnchair_larry 7y agoThis is completely unrelated to this class of issue. You’re thinking of stack-based buffer overlows. This is all about heap manipulation, and doesn’t involve an overflow. Not in that sense anyway.
- panpanna 7y agoWikipedia ROP article has a whole section on defense techniques https://en.m.wikipedia.org/wiki/Return-oriented_programming https://en.m.wikipedia.org/wiki/Return-oriented_programming Note that this was a heap attack (free after use)
- haecceity 7y agoControl flow integrity is the group of techniques meant to deal with this problem. There are settings for Microsoft’s cpp compiler to enable them but the best way to accomplish this is with a hardware shadow stack. Intel cet does this but I’m not sure when the hardware will be available.
- cjbprime 7y agoThere are already many modern mitigations present to defeat the kind of stack overflow control of the instruction pointer that you're imagining -- stack canaries, DEP, ASLR, NX, and others. Simply gaining control of the instruction pointer through a stack overflow as you describe stopped working a decade or so ago due to these mitigations.
- saagarjha 7y agoDEP and NX are essentially the same thing, FYI.