My program failed with segfault attempting to write "1" to a string.
(gdb) info frame
Stack level 0, frame at 0xb6b3c040:
eip = 0xb7877cdf; saved eip 0xb7858eae
called by frame at 0xb6b3cc50
Arglist at 0x91a1649, args:
Locals at 0x91a1649, Previous frame's sp is 0xb6b3c040
Saved registers:
ebx at 0xb6b3c02c, ebp at 0xb6b3c038, esi at 0xb6b3c030, edi at 0xb6b3c034, eip at 0xb6b3c03c
(gdb) bt
#0 0xb7877cdf in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0xb7858eae in vfprintf () from /lib/i386-linux-gnu/libc.so.6
#2 0xb787d91b in vsnprintf () from /lib/i386-linux-gnu/libc.so.6
#3 0x08ea7d7e in __gnu_cxx::__to_xstring<std::string, char> (__convf=0x85a2a50 <vsnprintf#plt>, __n=16, __fmt=0x91a1649 "%u") at /usr/include/c++/4.7/ext/string_conversions.h:95
#4 0x08ea6452 in std::to_string (__val=1) at /usr/include/c++/4.7/bits/basic_string.h:2871
...
I noticed that according to gdb, Arglist is not in stack. How it could happen? As far as I know, there is one calling convention in *nix: arguments are pushed to stack, caller clears stack frame. I went up and down through backtrace and everywhere else arglist was in stack.
You could be crashing in an assembly language routine that does not follow standard calling conventions and/or have symbolic information available.
Likely, the core issue is higher up than frame 0 anyway.
Related
I'm learning x32 ARM assembly on RaspberryPi with Raspbian. I wrote
the following code:
# Define my Raspberry Pi
.cpu cortex-a53
.fpu neon-fp-armv8
.syntax unified # modern syntax
.text
.align 2
.global main
.type main, %function
main:
mov r0, 1 # line added only for breakpoint purposes
sub sp, sp, 8 # space for fp, lr
str fp, [sp, 0] # save fp
str lr, [sp, 4] # and lr
add fp, sp, 4 # set our frame pointer
Build with gcc:
gcc -g test.s -o test
Use gdb to check values of fp and sp in lines 13 and 16 and
dereference them:
$ gdb ./test
(gdb) break 13
Breakpoint 3 at 0x103d4: file test.s, line 13.
(gdb) break 16
Breakpoint 4 at 0x103e0: file test.s, line 16.
(gdb) run
Starting program: /home/pi/assembly/nine/bob/test
Breakpoint 3, main () at test.s:13
13 sub sp, sp, 8 # space for fp, lr
(gdb) print {$sp, $fp}
$1 = {0x7efffae8, 0x7efffae8}
(gdb) x $sp
0x7efffae8: 0x76f9e000
(gdb) x $fp
0x7efffae8: 0x76f9e000
(gdb) continue
Continuing.
Breakpoint 4, main () at test.s:16
16 add fp, sp, 4 # set our frame pointer
(gdb) print {$sp, $fp}
$2 = {0x7efffae0, 0x7efffae0}
(gdb) x $sp
0x7efffae0: 0x00000000
(gdb) x $fp
0x7efffae0: 0x00000000
As you see fp is equal to sp at startup and non-zero:
(gdb) print {$sp, $fp}
$1 = {0x7efffae8, 0x7efffae8}
(gdb) x $sp
0x7efffae8: 0x76f9e000
(gdb) x $fp
0x7efffae8: 0x76f9e000
but when copied onto the enlarged stack it changes to zero
(gdb) x $fp
0x7efffae0: 0x00000000
Why does it change to zero? Why does it change value at all? Is
underlying implementation somehow linking values of fp and sp so
that when sp is moved down to the initialized memory that might be
all zeroes fp is changed as well? I only found
this:
fp
Is the frame pointer register. In the obsolete APCS variants that
use fp, this register contains either zero, or a pointer to the
most recently created stack backtrace data structure. As with the
stack pointer, the frame pointer must be preserved, but in
handwritten code it does not need to be available at every
instant. However, it must be valid whenever any strictly
conforming function is called. fp must always be preserved.
This
comment
says that lr is stored as the first element on the stack but it's
definitely not - it stays the same and is not zero:
(gdb) print {$sp, $fp, $lr}
$1 = {0x7efffae8, 0x7efffae8, 0x76e6b718 <__libc_start_main+268>}
and after sp changes:
(gdb) x/2xw $sp
0x7efffae0: 0x00000000 0x76e6b718
Ok, I'm answering myself - this happens in gdb/arm-tdep.c in GDB source code:
/* The frame size is just the distance from the frame register
to the original stack pointer. */
if (pv_is_register (regs[ARM_FP_REGNUM], ARM_SP_REGNUM))
{
/* Frame pointer is fp. */
framereg = ARM_FP_REGNUM;
framesize = -regs[ARM_FP_REGNUM].k;
}
else
{
/* Try the stack pointer... this is a bit desperate. */
framereg = ARM_SP_REGNUM;
framesize = -regs[ARM_SP_REGNUM].k;
}
I'm trying to write an ELF executable loader for x86-64 Linux, similar to this, which was implemented on ARM. Chris Rossbach's advanced OS class includes a lab that does basically what I want to do. My goal is to load a simple (statically-linked) "hello world" type binary into my process's memory and run it without execveing. I have successfully mmap'd the ELF file, set up the stack, and jumped to the ELF's entry point (_start).
// put ELF file into memory. This is just one line of a complex
// for() loop that loads the binary from a file.
mmap((void*)program_header.p_vaddr, program_header.p_memsz, map, MAP_PRIVATE|MAP_FIXED, elffd, program_header.p_offset);
newstack = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); // Map a page for the stack
if((long)newstack < 0) {
fprintf(stderr, "ERROR: mmap returned error when allocating stack, %s\n", strerror(errno));
exit(1);
}
topstack = (unsigned long*)((unsigned char*)newstack+4096); // Top of new stack
*((unsigned long*)topstack-1) = 0; // Set up the stack
*((unsigned long*)topstack-2) = 0; // with argc, argv[], etc.
*((unsigned long*)topstack-3) = 0;
*((unsigned long*)topstack-4) = argv[1];
*((unsigned long*)topstack-5) = 1;
asm("mov %0,%%rsp\n" // Install new stack pointer
"xor %%rax, %%rax\n" // Zero registers
"xor %%rbx, %%rbx\n"
"xor %%rcx, %%rcx\n"
"xor %%rdx, %%rdx\n"
"xor %%rsi, %%rsi\n"
"xor %%rdi, %%rdi\n"
"xor %%r8, %%r8\n"
"xor %%r9, %%r9\n"
"xor %%r10, %%r10\n"
"xor %%r11, %%r11\n"
"xor %%r12, %%r12\n"
"xor %%r13, %%r13\n"
"xor %%r14, %%r14\n"
:
: "r"(topstack-5)
:"rax", "rbx", "rcx", "rdx", "rsi", "rdi", "r8", "r9", "r10", "r11", "r12", "r13", "r14");
asm("push %%rax\n"
"pop %%rax\n"
:
:
: "rax");
asm("mov %0,%%rax\n" // Jump to the entry point of the loaded ELF file
"jmp *%%rax\n"
:
: "r"(jump_target)
: );
I then step through this code in gdb. I've pasted the first few instructions of the startup code below. Everything works great until the first push instruction (starred). The push causes a segfault.
0x60026000 xor %ebp,%ebp
0x60026002 mov %rdx,%r9
0x60026005 pop %rsi
0x60026006 mov %rsp,%rdx
0x60026009 and $0xfffffffffffffff0,%rsp
0x6002600d * push %rax
0x6002600e push %rsp
0x6002600f mov $0x605f4990,%r8
I have tried:
Using the stack from the original process.
mmaping a new stack (as in the above code): (1) and (2) both cause segfaults.
pushing and poping to/from the stack before jmping to the loaded ELF file. This does not cause a segfault.
Changing the protection flags for the stack in the second mmap to PROT_READ | PROT_WRITE | PROT_EXEC. This doesn't make a difference.
I suspect this maybe has something to do with the segment descriptors (maybe?). It seems like the code from the ELF file that I'm loading does not have write access to the stack segment, no matter where it is located. I have not tried to modify the segment descriptor for the newly loaded binary or change the architectural segment registers. Is this necessary? Does anybody know how to fix this?
It turned out that when I was stepping through the loaded code in gdb, the debugger would consistently blow by the first push instruction when I typed nexti and instead continue execution. It was not in fact the push instruction that was causing the segfault but a much later instruction in the C library start code. The problem was caused by a failed call to mmap in the initial binary load that I didn't error check.
Regarding gdb randomly deciding to continue execution instead of stepping: this can be fixed by loading the symbols from the target executable after jumping to the newly loaded executable.
I'm, currently struggling with the correct implementation of a kernel-spinlock in combination with a return statement which should return a value to userspace. I implemented a kernel syscall 'sys_kernel_entropy_is_recording' which should return the value of a kernel-variable 'is_kernel_entropy_recording':
asmlinkage bool sys_kernel_entropy_is_recording(void)
{
spin_lock(&entropy_analysis_lock);
return is_kernel_entropy_recording;
spin_unlock(&entropy_analysis_lock);
}
At this point arise two questions:
Q1: Is this implementation correct at all, meaning will the correct value of 'is_kernel_entropy_recording' be returned to userspace and afterwards the spinlock be released?
My concerns are:
a) is it allowed to return a value from kernelspace to userspace this way at all?
b) the return statement is located before the spin_unlock statement, hence will spin_unlock be even called?
Q2: To answer these question myself I disassembled the compiled .o file but determined (at least it looks for me like) the spin_lock/spin_unlock calls are completely ignored by the compiler, as it just moves the value of 'sys_kernel_entropy_is_recording' to eax an calls ret (I'm not sure about line 'callq 0xa5'):
(gdb) disassemble /m sys_kernel_entropy_is_recording
Dump of assembler code for function sys_kernel_entropy_is_recording:
49 {
0x00000000000000a0 <+0>: callq 0xa5 <sys_kernel_entropy_is_recording+5>
0x00000000000000a5 <+5>: push %rbp
0x00000000000000ad <+13>: mov %rsp,%rbp
50 spin_lock(&entropy_analysis_lock);
51 return is_kernel_entropy_recording;
52 spin_unlock(&entropy_analysis_lock);
53 }
0x00000000000000b5 <+21>: movzbl 0x0(%rip),%eax # 0xbc <sys_kernel_entropy_is_recording+28>
0x00000000000000bc <+28>: pop %rbp
0x00000000000000bd <+29>: retq
Hence I guess the application of spinlock is not correct.. Could someone please give me an advice for an appropriate approach?
Thanks a lot in advance!
It is prohibited to return from syscall with spinlock holded. And, as usual with C code, none instruction is executed after return statement.
Common practice is to save value obtained under lock into local variable, and return value of this variable after unlock:
bool ret;
spin_lock(&entropy_analysis_lock);
ret = is_kernel_entropy_recording;
spin_unlock(&entropy_analysis_lock);
return ret;
Two threads in same process using rwlock object stored in shared memory encounter crash during pthreads stress test. I spent a while trying to find memory corruption or deadlock but nothing so far. is this just an less than optimal way of informing me I have created a deadlock? Any pointers on tools/methods for debugging this?
Thread 5 "tms_test" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff28a7700 (LWP 3777)]
0x00007ffff761e428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff761e428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff762002a in __GI_abort () at abort.c:89
#2 0x00007ffff76607ea in __libc_message (do_abort=do_abort#entry=1, fmt=fmt#entry=0x7ffff77776cc "%s") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff766080e in __GI___libc_fatal (message=message#entry=0x7ffff79c4ae0 "The futex facility returned an unexpected error code.") at ../sysdeps/posix/libc_fatal.c:185
#4 0x00007ffff79be7e5 in futex_fatal_error () at ../sysdeps/nptl/futex-internal.h:200
#5 futex_wait (private=, expected=, futex_word=0x7ffff7f670d9) at ../sysdeps/unix/sysv/linux/futex-internal.h:77
#6 futex_wait_simple (private=, expected=, futex_word=0x7ffff7f670d9) at ../sysdeps/nptl/futex-internal.h:135
#7 __pthread_rwlock_wrlock_slow (rwlock=0x7ffff7f670cd) at pthread_rwlock_wrlock.c:67
#8 0x00000000004046e3 in _memstat (offset=0x7fffdc0b11a5, func=0x0, lineno=0, size=134, flag=1 '\001') at tms_mem.c:107
#9 0x000000000040703b in TmsMemReallocExec (in=0x7fffdc0abb81, size=211, func=0x43f858 "_malloc_thread", lineno=478) at tms_mem.c:390
#10 0x000000000042a008 in _malloc_thread (arg=0x644c11) at tms_test.c:478
#11 0x000000000041a1d6 in _threadStarter (arg=0x644c51) at tms_mem.c:2384
#12 0x00007ffff79b96ba in start_thread (arg=0x7ffff28a7700) at pthread_create.c:333
#13 0x00007ffff76ef82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)
It's pretty hard to debug something what is not documented well. I was trying to find any helpful information about "The futex facility returned an unexpected error code" but it seems that it isn't specified in futex documentation.
In my case this message was generated by sem_wait(sem), where sem wasn't valid sem_t pointer. I was accidentally overwriting it (the memory pointed by sem) with some random integers after initializing sem with sem_init(sem,1,1).
Try checking if you are passing valid pointer to locking function.
I was getting this error when i declared sem_t mutex as local variable.
I am working my way through an example in "The Shellcoder's Handbook". However, it is not going all that well. I am running a Debian 2.6.32-5-686 kernel, i386.
The following walkthrough is to guide the reader through the guts of what is happening when a buffer overflow occurs.
The program:
include <stdio.h>
include <string.h>
void return_input(void)
{
char array[30];
gets (array);
printf("%s\n", array);
}
int main ()
{
return_input();
return 0;
}
The aim of the game to to pass "AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDD" to the array which, in turn, will overwrite the return address with the excess 'D's.
I compiled like so:
gcc -ggdb -m32 -o test -fno-stack-protector -mpreferred-stack-boundary=2 test.c
I run gdb test and start investigating:
(gdb) disas return_input
Dump of assembler code for function return_input:
0x080483f4 <return_input+0>: push %ebp
0x080483f5 <return_input+1>: mov %esp,%ebp
0x080483f7 <return_input+3>: sub $0x24,%esp
0x080483fa <return_input+6>: lea -0x1e(%ebp),%eax
0x080483fd <return_input+9>: mov %eax,(%esp)
0x08048400 <return_input+12>: call 0x804830c <gets#plt>
0x08048405 <return_input+17>: lea -0x1e(%ebp),%eax
0x08048408 <return_input+20>: mov %eax,(%esp)
0x0804840b <return_input+23>: call 0x804832c <puts#plt>
0x08048410 <return_input+28>: leave
0x08048411 <return_input+29>: ret
End of assembler dump.
(gdb) break *0x08048400
Breakpoint 1 at 0x8048400: file test.c, line 7.
(gdb) break *0x08048411
Breakpoint 2 at 0x8048411: file test.c, line 9.
At this point we introduced two break points. One just before the call to gets. And another just before the function returns. Now we run it:
(gdb) run
Starting program: ./test
Breakpoint 1, 0x08048400 in return_input () at test.c:7
7 gets (array);
(gdb) x/20x $esp
0xbffff3ac: 0xbffff3b2 0xb7fca304 0xb7fc9ff4 0x08048440
0xbffff3bc: 0xbffff3d8 0xb7eb75a5 0xb7ff1040 0x0804844b
0xbffff3cc: 0xb7fc9ff4 0xbffff3d8 *0x0804841a* 0xbffff458
0xbffff3dc: 0xb7e9ec76 0x00000001 0xbffff484 0xbffff48c
0xbffff3ec: 0xb7fe18c8 0xbffff440 0xffffffff 0xb7ffeff4
This what the stack looks like just before the call to gets. I have marked the return address with asterisk (0x0804841a). Let's overwrite this:
(gdb) continue
Continuing.
AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDD
AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDD
Breakpoint 2, 0x08048411 in return_input () at test.c:9
9 }
(gdb) x/20x 0xbffff3ac
0xbffff3ac: 0xbffff3b2 0x4141a304 0x41414141 0x41414141
0xbffff3bc: 0x42424242 0x42424242 0x43434242 0x43434343
0xbffff3cc: 0x43434343 0x44444444 *0x44444444* 0xbf004444
0xbffff3dc: 0xb7e9ec76 0x00000001 0xbffff484 0xbffff48c
0xbffff3ec: 0xb7fe18c8 0xbffff440 0xffffffff 0xb7ffeff4
The above is what the stack looks like just before returning from the function. As you can see, we've overwritten the return address with those excess 'D's. Result. Let's finish up:
(gdb) x/li $eip
0x8048411 <return_input+29>: ret
(gdb) stepi
Cannot access memory at address 0x44444448
Um, eh? This 0x44444448 has come from the arse-end of nowhere. Somehow gcc has modified the return address just before we return. Thanks.
Any ideas? Am I correct in assuming gcc has done its own internal checking whether the return address is valid. And if not, it's stuck some crap in it to prevent us from crafting a nasty return address?
Any way around this? I've tried everything here - http://www.madhur.co.in/blog/2011/08/06/protbufferoverflow.html. Same result.
This is the expected result—a page fault. Your program ist stopped by the operating system because you are accessing virtual memory that is not assigned to any physical memory.
The message you see is just the debugger notifying you of that fact.