Hacker News Reader

Hacker News

Comment by hayley-patton | Hacker News Reader

Full thread

hayley-patton

> What can we do to prevent ROP attacks?

No mention of bounds checks?

View on HN

FTA:

> A successful ROP attack needs the following ingredients:

> buffer overflow vulnerable application

Also, this article is about constructing the program to run using ROP, not about calling it. It’s only the latter that requires an exploit, typically from a buffer overflow.

Right, but the ROP program is of no use if it can't be called, as stated in that quote. Hence bounds checks also avoid that class of exploits.

Bounds checks are a high-level language construct. A processor executes machine code which has no concept of bounds check. A processor needs to execute every sequence of machine instructions, including those from languages without bounds checks.

Though you can have memory pages which are non-executable so I'd say that the processor in fact has this concept.

Yes, if you see memory as a page-size-grained array, you can see that they are similar concepts.

The whole point of ROP is to get around this. Rather than executing code that you've sprayed on the heap, you jump to gadgets that are already in the binary to construct your program.

Then the other software mitigations listed in the article are not so useful either, because the implementation (and OS, in the case of ASLR) could choose not to use them, and the processor should execute such code too.

Defense works in layers: bounds checking is a programming language technique (although you can typically switch it off in (some) compilers). ASLR is an OS technique, which works even if bonds checks are switched off. IIRC at some point one OS (Debian?) had a bug in the randomness generation for ASLR, and it was easy to circumvent ASLR because of that.

All you need to defeat ASLR is a data exfil so you can dump the process code. A great paper (https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...) from about a decade ago created fully automated ROP against ASLRed processes (though it did rely on the fact that fork() didn't rerandomize on linux at the time).

There are processors with support for bounds checking and hardware memory tagging.

ARM being one of them.

Reply on news.ycombinator.com