2

I'm trying to better understand my computer on the lower levels and what better way is there other than writing stack buffer overflow exploits? I recently came across ROP. I read the paper http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html and it mentioned there was a compiler for ROB code. What is the name of such a compiler for linux (64bit)?

Thanks, Konstantin

Konstantin Weitz
  • 6,180
  • 8
  • 26
  • 43

1 Answers1

7

I was one of the researchers on this project at UCSD and wrote the C-to-exploit-string compiler portion. The specific work you are referring to was SPARC-specific (and further tailored to a known Solaris libc binary). These papers actually give a better overview of what we did (and generalizations and programming approaches):

For Linux + x64, there have been many tools for ROP attack creation since our research, which you can find generally by searching the web. And most of these are far more useful and user-friendly than our (now relatively old) research-specific tools.

Let me just offer a suggestion that if you want to understand the lower levels of your Linux system and haven't already done so, consider a "stepped" approach with the following:

  1. "Old-School" Stack Injection: Disable non-executable stack protection on your box, and just inject shell code. Lot's of resources here -- start with Aleph One's seminal "Smashing The Stack For Fun And Profit" (widely available on the web).
  2. Return-to-Libc: Re-enable non-executable stacks, and try to create a custom payload to jump into libc (probable execve) and try to grab a shell.

Once you've got a handle on those, then getting in to ROP will be a lot easier. If you're already there, then power to you!

Ryan Roemer
  • 987
  • 7
  • 13
  • Ryan, I'm trying to understand how it works. I'm a ROP newbie and I'm starting on SPARC, because I'm developing an exploit. I just learned return to LibC but the caller function borks the %i0 register before it gets to system() as %i0 with /bin/sh.. I thought ROP might be able to save me, where I could intermediately call a small suffix function to restore %o0 from one of the other registers I've overflowed.. I almost started to understand it with the diagrams in the updated manuscript demonstrating how the %sp leads the way in ROP, but then I lost it... – bazz Oct 16 '14 at 12:56
  • continuation of above comment: AFAIK, I am exploiting a remote program I cannot know the stack offset without brute force.. When I overwrite the %fp and %i7, I write %fp with some random qualifying stack address, I am aware that it becomes the %sp after the ret restore into infected %i7. This %sp then becomes the basis for the %i7 in the new stack frame, right?! which is why I don't understand how I could possibly control multiple levels of returns on the SPARC :| – bazz Oct 16 '14 at 13:02
  • Hi bazz, Thanks for your interest! Did you make your way through the entire CCS 2008 paper? The difficulty in ROP on SPARC is the sliding register window and preparing things to roll up after the return. It's not clear if you've got ASLR on, if so things get much more difficult (we didn't tackle this in our paper). As long as ASLR is off and you have a "conventional" strcpy or other exploit available, you basically need to backtrace where all the registers should be once the function returns and the paper should give you the high-level there. – Ryan Roemer Nov 03 '14 at 21:47
  • I figured out how to do it. Thanks for response. – bazz Nov 04 '14 at 20:23