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!

Improve this question
11
  • If you step into the call system, does it actually end up in the correct place?
    – Igor Skochinsky ♦
    May 23, 2018 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, 2018 at 7: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, 2018 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, 2018 at 22:34
  • 1
    You can read this answer. Everything should be in it.
    – perror
    May 27, 2018 at 20:35

1 Answer 1

Reset to default
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.

Improve this answer
3
  • 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, 2018 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, 2018 at 1:13
  • --buffer--address of system--fake return address--address of /bin/sh
    – DeepS1X
    May 29, 2018 at 1:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.