5

doing an assignment for university.

We have to exec a shell on a remote server. We're told the NX bit is not set, however, when we redirect to our injected code, the server has a segmentation fault. Am I right in thinking that the bit is, in fact, set in this case? The injected code is a load of NOPs followed by some shell code in a buffer. We overwrite the EIP to redirect to near the start of the buffer (in the NOP slide) but instantly we get a seg fault.

Thanks for any help!

Richard
  • 385
  • 2
  • 9

1 Answers1

8

If you are stepping through one instruction at a time, and the segfault occurs immediately upon jumping (and not when hitting some potentially broken shellcode at the end of the NOP sled, which could also cause a segfault), and you are certain that the address is correct, points to valid memory and that your NOP sled itself isn't broken, then yes it seems plausible that the segfault is being caused by DEP.

However, the other things I list above are more likely in my opinion, and there are lots of other reasons why a segfault might pop up.

Just so we're certain you've got everything right in gdb;

You should have a breakpoint just before the return instruction you have corrupted. You can do this via the disas and break commands.

Once the program hits your breakpoint, you want to check the lay of the land. Check eip with the info r command. And have a look at your stack using things like x/40x $esp. You should be able to see your nop sled, shellcode, and return address repeatedly afterwards. Another note that just came to mind; the return address has to be aligned properly, usually this means putting 1-3 nops after your shellcode to shove it into place.

If all looks well, then it's time to run a step. If info r now reports that eip contains an address that is on your nop sled - check this with a x %eip, you should see 0x90909090. Then hit step again. If at this point you get a segfault, then yes (to answer your original question :P) you have DEP turned on IMHO.

Sorry if that was all stuff you already knew, it's just vital to check everything several times when you're playing with memory exploits.

lynks
  • 10,636
  • 5
  • 29
  • 54
  • Thanks for that. We're redirecting to the start of the buffer (whose address we extracted through gdb (let's say 0xb7eeff30)), and gdb tells us we are segfaulting at the same location. NOP sled is a series of bytes set to \x90. – Richard Dec 07 '12 at 19:46
  • Are your `0x90`s properly aligned? Is your return address of the correct endianess? – lynks Dec 07 '12 at 19:56
  • Yeah the address is correct (I can send the server to execute other functions just fine). The attack string begins with buffer length - shellcode length 0x90s, should it have a different form? – Richard Dec 07 '12 at 20:11
  • Yep that sounds about right, I'll edit my answer with a few GDB hints, see if we can nail the problem. – lynks Dec 07 '12 at 20:21
  • Yeah none of that worked. It must be that the stack is not executable. – Richard Dec 07 '12 at 21:13
  • It must be, if you have managed to write to a location, but get a segfault when you try to execute that location, then DEP is turned on. – lynks Dec 07 '12 at 21:15
  • Looks like it's time to ROP to mmap/VirtualProtect then. – Polynomial Dec 12 '12 at 11:21