i'm trying to execute a buffer overflow attack on a program written in c, i'm using GNU/Linux (Ubuntu 16.04 LTS).
this is the source code:
#include<stdio.h>
void CALLME(){
puts("successful!");
}
int main(void){
char s[16];
scanf("%s",s);
}
what i want to do is override the return address of main so that after main function, the function CALLME will be executed.
i compile the program with
gcc -m32 -fno-stack-protector -o prog prog.c
use command:
nm prog | grep CALLME
i got the address of CALLME: 0804845b
disassemble main in gdb i found that: during main function, the return address is located at 8(%ebp) and the address of string s is at -0x18(%ebp). So the difference is 0x8 + 0x18 = 32
i try to exploit:
perl -e 'print "a" x 32 . "\x5b\x84\x04\x08"' | ./main
it didn't work.
Segmentation fault (core dumped)
Why ? Is main function more special ? Because in other functions (i made) that have a similar vulnerability it works ?
NOTE: i don't think about ASLR, some guys said that happens only when i compile gcc -pie ... and other stuffs.
Related
I have this program:
double t;
main() {
}
On Ubuntu, I run:
% gdb a.out
(gdb) p &t
$1 = (double *) 0x4010 <t>
(gdb) run
Starting program: /home/phan/a.out
[Inferior 1 (process 95930) exited normally]
(gdb) p &t
$2 = (double *) 0x555555558010 <t>
Why did the address change from 0x4010 to 0x555555558010. Is there someway to prevent this?
On Redhat, it doesn't do that:
% gdb a.out
(gdb) p &t
$1 = (double *) 0x601038 <t>
(gdb) r
Starting program: /home/phan/a.out
[Inferior 1 (process 23337) exited normally]
(gdb) p &t
$2 = (double *) 0x601038 <t>
BTW, this only occurs in Ubuntu 18.04. In Ubuntu 16.04, it works exactly as Redhat, for example the address is the same before and after.
You are presumably seeing pre and post-relocation addresses for the .bss segment.
You can avoid this by disabling position independent executables, thus making gcc choose the final address of the .bss register up front:
gcc -no-pie foo.c
-static would have the effect.
I don't know why there'd be a difference between Ubuntu and Redhat though.
We are using dlopen to read in a dynamic library on Mac OS X. Update:
This is a posix problem, the same thing fails under cygwin.
First the compile. On cygwin:
extern "C" void foo() { }
g++ -shared foo.c -o libfoo.so
nm -D libfoo.so
displays no public symbols. This appears to be the problem. If I could make them public, nm -D should display them.
Using:
nm libfoo.so | grep foo
000000x0xx0x00x0x0 T _foo
you can see the symbol is there. In Linux, this does seem to work:
nm -D foo.so
0000000000201020 B __bss_start
w __cxa_finalize
0000000000201020 D _edata
0000000000201028 B _end
0000000000000608 T _fini
0000000000000600 T foo
w __gmon_start__
00000000000004c0 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
However, even in Linux, we cannot seem to connect to the library. Here is the source code:
include
include
using namespace std;
int main() {
void* so = dlopen("foo.so", RTLD_NOW);
if (so = nullptr) {
cerr << "Can't open shared library\n";
exit(-1);
}
#if 0
const void* sym = dlsym(so, "foo");
if (sym == nullptr) {
cout << "Symbol not found\n";
}
#endif
dlclose(so);
}
If we remove the #ifdef, the above code prints "Symbol not found"
but it crashes on the dlclose.
We tried exporting LD_LIBRARY_PATH=. just to see if the library cannot be reached. And the dlopen call seems to work in any case, the return is not nullptr.
So to summarize, the library does not seem to work on Mac and Cygwin. On Linux nm -D shows the symbol in the library, but the code to load the symbol does not work.
In your example, you wrote if (so = nullptr) {, which assigns nullptr to so, and the condition is always false. -Wall is a good idea when debugging!
This alone explains why you can't load the symbol, but I also found that I needed to do dlopen("./foo.so", RTLD_NOW); because dlopen otherwise searches library paths, not the current directory.
I try to compile simple utility (kernel 3.4.67), which
all it does is trying to use system call very simply as following:
int main(void)
{
int rc;
printf("hello 1\n");
rc = system("echo hello again");
printf("system returned %d\n",rc);
rc = system("ls -l");
printf("system returned %d\n",rc);
return 0;
}
Yet, system call fails as you can see in the following log:
root#w812a_kk:/ # /sdcard/test
hello 1
system returned 32512
system returned 32512
I compile it as following:
arm-linux-gnueabihf-gcc -s -static -Wall -Wstrict-prototypes test.c -o test
That's really wierd becuase I used system in past in different linux and never had any issue with it.
I even tried another cross cpompiler but I get the same failure.
Version of kernel & cross compiler:
# busybox uname -a
Linux localhost 3.4.67 #1 SMP PREEMPT Wed Sep 28 18:18:33 CST 2016 armv7l GNU/Linux
arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) 4.7.3 20130226 (prerelease)
EDIT:
root#w812a_kk:/ # echo hello again && echo $? && echo $0
hello again
0
tmp-mksh
root#w812a_kk:/ #
But I did find something interesting:
On calling test_expander() withing the main, it works OK. so I suspect that maybe system call try to find a binary which is not founded ?
int test_expander(void)
{
pid_t pid;
char *const parmList[] = {"/system/bin/busybox", "echo", "hello", NULL};
if ((pid = fork()) == -1)
perror("fork error");
else if (pid == 0) {
execv("/system/bin/busybox", parmList);
printf("Return not expected. Must be an execv error.n");
}
return 0;
}
Thank you for any idea.
Ran
The return value of system(), 32512 decimal, is 7F00 in hex.
This value is strangely similar to 0x7F, which is the result of system() if /bin/sh can not be executed. It seems there is some problem with byte ordering (big/little endian). Very strange.
Update: while writing the answer, you edited the question and pulled in something about /system/bin/busybox.
Probably you simply don't have /bin/sh.
I think I understand what happens
From system man page:
The system() library function uses fork(2) to create a child process
that executes the shell command specified in command using execl(3)
as follows:
execl("/bin/sh", "sh", "-c", command, (char *) 0);
But in my filesystem sh is founded only /system/bin , not in /bin
So I better just use execv instead. (I can't do static link becuase it's read-only filesystem)
Thanks,
Ran
I am compiling a C program on linux with gcc. The program itself links libc (and not much else) at build-time, so that ldd gives this output :
$ ldd myprogram
linux-vdso.so.1 => (0x00007fffd31fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a991c0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7a99bba000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7a98fbb000)
At run-time this program dlopen()s library B, which dependes on a library A, which of course dlopen also loads before returning. A exports a function called re_exec, which B invokes (B is linked against A). libc also exports a function called re_exec. readelf output :
$ readelf -as A.so | grep re_exec
104: 00000000000044ff 803 FUNC GLOBAL PROTECTED 11 re_exec
469: 00000000000044ff 803 FUNC GLOBAL PROTECTED 11 re_exec
$ readelf -as /lib/x86_64-linux-gnu/libc.so.6 | grep re_exec
2165: 00000000000e4ae0 39 FUNC WEAK DEFAULT 12 re_exec##GLIBC_2.2.5
The problem is that when B invokes re_exec, the re_exec inside libc is called, NOT the re_exc inside of A.
If, when I invoke the program, I include LD_LIBRARY_PRELOAD=/path/to/A.so, then everything works as expected : Bs invocation of re_exec correctly calls A, and not libc.
The dlopen call passes RTLD_NOW | RTLD_GLOBAL. I have tried with and without DEEPBIND, and get the same behavior in either case.
I have also tried dlopen()ing A directly, before B, both with and without DEEPBIND, which did not affect the behavior.
The question : is it possible to dlopen A/B with higher precedence than libraries that were included at link-time (libc, in this case) ?
(please don't suggest that I rename the call to something other than re_exec ; not useful)
Well, you know, I can't reproduce your error. Please take a look:
puts.c:
#include <stdio.h>
int puts(const char* _s) {
return printf("custom puts: %s\n", _s);
}
built with:
cc -Wall -fPIC -c puts.c -o puts.o
cc -shared -o libputs.so -fPIC -Wl,-soname,libputs.so puts.o
foo.c:
#include <stdio.h>
void foo() {
puts("Hello, world! I'm foo!");
}
built with:
cc -Wall -fPIC -c foo.c -o foo.o
cc -L`pwd` -shared -o libfoo.so -fPIC -Wl,-soname,libfoo.so foo.o -lputs
and rundl.c:
#include <dlfcn.h>
#include <assert.h>
#include <stdio.h>
typedef void (*FooFunc)();
int main(void) {
void *foolib = dlopen("./libfoo.so", RTLD_NOW | RTLD_GLOBAL | RTLD_DEEPBIND);
assert(foolib != NULL);
FooFunc foo = (FooFunc)dlsym(foolib, "foo");
assert(foo != NULL);
foo();
return 0;
}
built with:
cc -c -Wall rundl.c -o rundl.o
cc -o rundl rundl.o -ldl
now we can run rundl with LD_LIBRARY_PATH=$(pwd) (it's needed because libputs.so isn't in the ld.so known paths so libfoo.so can't be loaded w/ dlopen() & Co):
alex#rhyme ~/tmp/dynlib $ LD_LIBRARY_PATH=`pwd` ./rundl
custom puts: Hello, world! I'm foo!
alex#rhyme ~/tmp/dynlib $ _
if we move libputs.so to a directory known to ld.so and (re)run ldconfig to update caches then the code runs without any special environment variables:
alex#rhyme ~/tmp/dynlib $ ldd ./libfoo.so
linux-vdso.so.1 (0x00007fff48db8000)
libputs.so => /usr/local/lib64/libputs.so (0x00007f8595450000)
libc.so.6 => /lib64/libc.so.6 (0x00007f85950a0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8595888000)
alex#rhyme ~/tmp/dynlib $ ./rundl
custom puts: Hello, world! I'm foo!
If I link libfoo.so w/o -lputs foo() invokes the standard puts() from libc. That's it.
I am building a 16 bit operating system. But character array does not seem to work.
Here is my example kernel code:
asm(".code16gcc\n");
void putchar(char);
int main()
{
char *str = "hello";
putchar('A');
if(str[0]== 'h')
putchar('h');
return 0;
}
void putchar(char val)
{
asm("movb %0, %%al\n"
"movb $0x0E, %%ah\n"
"int $0x10\n"
:
:"m"(val)
) ;
}
It prints:
A
that means putchar function is working properly but
if(str[0]== 'h')
putchar('h');
is not working.
I am compiling it by:
gcc -fno-toplevel-reorder -nostdinc -fno-builtin -I./include -c -o ./bin/kernel.o ./source/kernel.c
ld -Ttext=0x9000 -o ./bin/kernel.bin ./bin/kernel.o -e 0x0
What should I do?
Your data segment is probably not loaded in to the target. What are you doing after the link with your brand new kernel.bin file, which is in fact an elf file ?