2

I am learning buffer overflow exploits in Linux x86 binaries. I am doing a classic stack smashing to spawn a root shell in a Ubuntu 12.04 VM by disabling ASLR and compiling the binary by disabling NX bit and stack canaries.

During my execution the return address is getting overwritten and the shellcode is getting executed, but I am not getting root shell, instead it results in a bash shell.

To mitigate bash protection, I am using zsh shell and I have removed sh->bash symbolic link and created a symbolic link of sh with zsh shell in /bin directory

I have tried with a setuid enabled binary owned by root ( execute permission for other user), but still I am not getting root shell.

I have verified my shell code with C program and while by compiling the test program(of my shell code) and executing it after making it setuid enabled. so the test program is giving root shell. But I am not able to get the root shell when the same shellcode is used with buffer overflow..

When I am debugging this scenario in gdb, during overflow /bin/zsh4 is getting executed but results in a bash shell.

Even I am not able to get root shell with a return to libc attack also. That also results in a bash shell. I have tried these steps in Ubuntu 12.04, Ubuntu 11.04 and Ubuntu9 but still the result is same.

I am beginner in this area. So there might be some mistakes I have done in any of the above steps. So could any of you please advice what could be the possible issue and how to resolve it

user2103885
  • 51
  • 1
  • 5
  • Are you sure the binary you are attacking is itself running as `root`? – merlin2011 Mar 31 '14 at 19:22
  • Do you run the binary (with sticky bit) and NOT in gdb ? Also, "To mitigate bash protection, I am using zsh": what do you mean (not familiar with zsh) ? What could be the benefit (spawning a new shell as root spawns a root shell if that is your concern) ? Did you try with a standard /bin/sh pointing on /bin/bash (and not in gdb) ? – naab Mar 31 '14 at 19:34
  • @merlin2011 I have changed the ownership of the binary to root and enabled setuid on it. – user2103885 Mar 31 '14 at 21:49
  • @naab, I ran the binary with s bit enabled. I have tried sh pointing to bash as well as dash shell too. But I am not getting root shell. I am able to do this attack outside gdb also but the shell I am getting as a result is a bash shell. I tried with zsh also because, I heard bash and dash shell will drop privilege if I execute /bin/sh from a setuid program. Please correct me if I am wrong – user2103885 Mar 31 '14 at 21:51
  • @user2103885, I understand that the binary is `setuid`. My question is, when you launch the binary, is the shell *from which you launch the binary* a root shell? – merlin2011 Mar 31 '14 at 23:24
  • @merlin2011 , I am invoking the binary from a bash shell. – user2103885 Apr 01 '14 at 02:41
  • @user2103885, "I heard bash and dash shell will drop privilege if I execute /bin/sh from a setuid program." It's not totally true, on most distributions, the setuid is disabled for **scripts** (ex: somescript.sh which starts with a leading #!/bin/bash), not /bin/sh execution from an application with setuid. And btw, how do you check that your shell is a root shell ? id? whoami? (you won't necessarily get a # when getting a root shell) – naab Apr 01 '14 at 17:21

1 Answers1

3

Finally I figured out the reason for this error.

During my execution my root privilege was dropped because I had disabled ptrace of process system level to work on another tool. I had overwritten /proc/sys/kernel/yama/ptrace_scope value to 0. This was the reason for not getting root shell for me.

I found this information from the man page of execve ( which I was using for creating shellcode):

If the set-user-ID bit is set on the program file pointed to by filename, and the underlying file system is not mounted nosuid (the MS_NOSUID flag for mount(2)), and the calling process is not being ptraced, then the effective user ID of the calling process is changed to that of the owner of the program file. Similarly, when the set-group-ID bit of the program file is set the effective group ID of the calling process is set to the group of the program file.

So now when I am not disabling ptrace_scope , I am getting a root shell.

Thanks merlin2011 and naab for being part of this discussion.

jww
  • 97,681
  • 90
  • 411
  • 885
user2103885
  • 51
  • 1
  • 5