3

I'm working on a buffer overflow CTF challenge. The binary for this challenge includes a give_shell function (they cover shellcode in the next challenge)

I can successfully overwrite the saved EIP on the stack to redirect execution to the 'give_shell' function:

080484cb  push    ebp
080484cc  mov     ebp, esp
080484ce  sub     esp, 0x8
080484d1  sub     esp, 0xc
080484d4  push    0x80485f0 {var_1c}  {"/bin/sh"}
080484d9  call    system
080484de  add     esp, 0x10
080484e1  nop     
080484e2  leave    {__saved_ebp}
080484e3  retn

However, even though I can confirm in GDB that the program is stepping through the give_shell function - no shell launches, either in GDB, locally or using Netcat to the actual CTF server.

I'm unsure what I am missing here. Is this a case where I need to bind or reverse the shell in order to be able to use it interactively? I've seen that discussed in shellcode examples, but not sure how to do it in this case.

Thank you!

BronzeOtter
  • 363
  • 1
  • 4
  • 11
  • If you step into the call system, does it actually end up in the correct place? – Igor Skochinsky May 23 '18 at 21:29
  • If you're on a Linux system with a custom shell (e.g bash). could you try statically patching the "/bin/sh" string by changing it to "/bin/bash" for example (hopefully, the length wouldn't be an issue or would only shorten a consecutive string). And have you tried running the program/gdb as root? Also, may I ask which CTF series it is from? – Elian Kamal May 24 '18 at 07:23
  • @igor-skochinsky Thanks for your comment. Your question is a great one and I'm not sure I have a full answer. I CAN stepi into system@plt - however, once I'm in system@plt I can nexti through it, however GDB will not allow me to disass system@plt - when I try it responds No symbol "plt" in current context. - not sure if that's because there is something special about system@plt or it is because something is wrong. I can attach a screen cap if needed. Thank you! – BronzeOtter May 24 '18 at 22:31
  • @elian-kamal Thank you for your comment! Running gdb as root gets the same non-result. No shell is launched. This is a challenge from the Recruit CTF series, which is a fantastic (but fairly tricky) intro series. – BronzeOtter May 24 '18 at 22:34
  • @IgorSkochinsky Thanks again for your comment. I was able to stepi into system and it actually seems a bit strange. When you disass system, you see: Dump of assembler code for function system@plt: => 0x08048390 <+0>: jmp *0x804a014 0x08048396 <+6>: push $0x10 0x0804839b <+11>: jmp 0x8048360 - however the odd thing is that the last jmp to 0x8048360 seems to go nowhere. GDB only returns 0x08048360 in ?? () and No function contains specified address. - which seems odd? – BronzeOtter May 25 '18 at 16:12
  • @BronzeOtter this is normal when you don’t have symbols – Igor Skochinsky May 25 '18 at 19:51
  • @BronzeOtter: How do you inject your overflow ? Through argv[] or through stdin ? If it is though stdin you might miss way to keep open the stream to the vulnerable program. – perror May 26 '18 at 10:05
  • @perror Thank you for the comment! The overflow uses stdin - I too was wondering if I was missing a way to reach the shell once it's launched. How does one go about doing that when not using shell code? Any pointers? Thanks again! – BronzeOtter May 27 '18 at 20:31
  • 1
    You can read this answer. Everything should be in it. – perror May 27 '18 at 20:35
  • @perror FANTASTIC. That covered everything. I'd suspected that this was the problem, but was unable to find the right resource for the information on how to access the shell. Thank you. I'd like to move this over to an answer - how to I make sure you're credited for the answer and not me? – BronzeOtter May 27 '18 at 21:34
  • If the question and the answer I pointed are suitable to you, vote for it. This will be enough. – perror May 27 '18 at 21:38

1 Answers1

1

Calling system@plt implies that you are calling system through the procedure linkage table, instead of directly. I would suggest pointing EIP at the address of the system function instead of at the plt version, as that tends to work reliably.

DeepS1X
  • 111
  • 1
  • Was thinking about this as well. Problem is that the challenge in this case is to point execution to a give_shell function that calls system and supplies the correct argument to open a shell. Calling the system function directly would leave it without the correct argument, correct? Thank you! – BronzeOtter May 27 '18 at 20:33
  • When doing a ret2libc exploit, if you provide the the stack looking like this, you will be able to get a shell: – DeepS1X May 29 '18 at 01:13
  • --buffer--address of system--fake return address--address of /bin/sh – DeepS1X May 29 '18 at 01:14