undefined | Better HN

0 pointsgarblegarble10y ago0 comments

It looks like it's an exploit technique where the stack is modified to set up malicious calls to functions: https://en.wikipedia.org/wiki/Return-oriented_programming

0 comments

mafribe10y ago

That's not really the essence of ROP because other attack techniques often also need to manipulate the stack. The key novel idea in ROP is to use data in unintended ways. This is based on the insight that the memory often contains short sequences of bytes (e.g. a .jpg image) that can be interpreted as machine instructions. For example an mp3 file might contain the sequence 99 19933, 16 which translates to

    increment register 16
    return

in the ambient machine language. Call that "dual use data". ROP searches the memory for sufficient "dual use data" and then builds an ac-hoc compiler with "dual use data" as target language. Then the attack software compiles to "dual use data" and then runs the compiled code.

Of course one may ask: can we always find enough "dual use data" to build a Turing-complete set of instructions as a compilation target. Turns out that with high probability that is the case.

tptacek10y ago

ROP gadgets are usually harvested from libraries loaded into the program, not MP3 files.

The key novel idea in ROP is to use instruction sequences in unintended ways. ROP is a refinement of ret2libc, improving on it by returning into arbitrary locations in functions rather than their entry points. That, and of chaining together gadgets with returns. Hence the name.

mafribe10y ago

It is true that "ROP gadgets are usually harvested from libraries loaded into the program, not MP3 files", but that's not because there's something intrinsically wrong with mp3s as source of gadgets, it's just that mp3s are often not executable. I have emphasised mp3s and jpgs precisely to emphasise what' novel about ROP, namely that any data can be used as machine language.

1 more reply

Dylan1680710y ago

None of that should be marked executable, though. The real risk in ROP is using little bits of legitimate functions to bypass DEP.

mafribe10y ago

That is true, I should have been more clear about this but you don't use the "legitimate function"'s intended functionality, you only use the fact that it can be execute (and the byte-string that is it's code).

I used mp3s and jpgs as extreme examples of data that was never intended to be executed, but still can be interpreted as code. In ROP, you don't care about the intended meaning of the bytes that make up "legitimate functions" (or any other data you may use) for it's unlikely to have the sought functionality. Instead you use you search for "dual use code" too, and piece together the functionality you need.

1 more reply

kevin_thibedeau10y ago

You may however be able to get different legitimate instructions than originally intended by jumping to an address in the middle of a multi-byte instruction that happens to decode into a useful series of operations. It follows that there are more usable "returns" in a body of code than just those written in the original source.

1 more reply

j / k navigate · click thread line to collapse

0 comments

mafribe10y ago

    increment register 16
    return

Of course one may ask: can we always find enough "dual use data" to build a Turing-complete set of instructions as a compilation target. Turns out that with high probability that is the case.

tptacek10y ago

ROP gadgets are usually harvested from libraries loaded into the program, not MP3 files.

mafribe10y ago

1 more reply

Dylan1680710y ago

None of that should be marked executable, though. The real risk in ROP is using little bits of legitimate functions to bypass DEP.

mafribe10y ago

1 more reply

kevin_thibedeau10y ago

1 more reply

j / k navigate · click thread line to collapse