5 ms·
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_progra
by garblegarble 11y ago
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 https://en.wikipedia.org/wiki/Return-oriented_programming
- mafribe 11y agoThat'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.
- Dylan16807 11y agoNone of that should be marked executable, though. The real risk in ROP is using little bits of legitimate functions to bypass DEP.
- mafribe 11y agoThat 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.
- revelation 11y agoWell, but you missed that data can not be executed. Unless you store your MP3s and jpegs in .text, the memory pages all that stuff is in are marked not executable and will only cause a crash if you jump to it. Regardless of whether the bytes make useful instructions.
- mafribe 11y agoData can be executed if it is in the executable part of the memory. There is quite a lot of such data. In particular, code is data!
- mafribe 11y agoWhy is this post downvoted? This idea of (mis)using code is part of the essence of ROP! Could somebody please explain where I'm wrong, so I can learn?
- tptacek 11y agoI didn't downvote it, but I feel like your comments have been technically correct but practically misleading. It's possible to have executable data, but if you do, you generally have bigger problems: the exploit can simply write a complete first-stage into the data and execute it directly, and not bother going through return-oriented contortions. The reality is that gadget harvesting is about analyzing program text --- actual binary machine instructions --- not about looking for ways to interpret JPEGs or MP3s or (I wrote DOCX and then PDF and then thought "huh bad examples") RTF files as instruction streams. It's also true that you can exploit insane x86 encoding to synthesize unintended instructions, but that's (I think) less important than the simpler idea of taking whole assembled programs, harvesting very small subsequences, wiring them together with a forged series of stack frames, and achieving general computation.
- TheLoneWolfling 11y agoRight. But in practice ROP targets the executable portions - any and all of them. If someone leaves something executable that they shouldn't, it'll use that. If only code is left executable, it's still often able to use that. Remember, x86 can be parsed differently depending on offset. You jump into the middle of a multibyte instruction you get an entirely different instruction stream. And x86 doesn't have any real protection against that.
- kevin_thibedeau 11y agoYou 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.
- tptacek 11y agoThere are a multiple usable "returns" in functions because "return" is just "pop" then "jump", so a block that has the effect of manipulating the stack and then transferring control can often be used to the same effect as a return.
- kevin_thibedeau 11y agoon 32-bit x86 the RET instructions are 0xC3 and 0xCB. Any other instruction containing these bytes can be subverted into a return if you can make the processor read the preceding instructions from the wrong starting point.
- tptacek 11y agoROP 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.
- mafribe 11y agoIt 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.
- tptacek 11y agoYeah this just doesn't seem like an illuminating example in practice. In practice, gadgets for ROP chains are harvested from program text. It's for that reason that so much effort is expended in many exploits on memory leaks that reveal the locations of libraries loaded into memory.