Why does this program causes a segfault?

Question

I am currently writing about stack overflows and created the following program below (for reference, I am using a 32-bit linux machine):

#include <stdio.h>
#include <string.h>

int main () {
    char foo[16];
    strcpy(foo, "AAAAAAAAAAAAAAAABBBBC");
}

This program was compiled with

 gcc stack_buffer_2.c -g -o stack_buffer_2 -fno-stack-protector

What this program does is:

fill all "foo" array with 'A' chars
fill saved EBP with 'B' chars
write 'C' char (plus null char) to saved ESP

I verified the behavior of this program in GDB andhere is what I got:

(gdb) run

Program received signal SIGSEGV, Segmentation fault.
0xb7e30043 in ?? () from /lib/i386-linux-gnu/libc.so.6

The program tried to jump to 0xb7e30043 (overflown value, with 0x43 and null terminator) instead of the original value 0xb7e31637, which is a return point from __libc_start_main, in this context.

Here is where things get tricky for me. Doing a "info proc mappings", I see that 0xb7e30043 seems to be like "valid" memory (inside /lib/i386-linux-gnu/libc.so.6)

I am aware that segfaults can be triggered by memory I don't "own", or to unmapped segments. But in this case, since this is inside the memory space from my application, and libc is mapped to it, why I am getting a segfault?

I suspect this is due to some kind of misalignment, since after the overflow EIP is pointing to a random instruction inside libc. If it is, how can I adjust it? What are the constraints behind it, and who enforces it? The kernel, the MMU?

Unless you haven't loaded the glibc symbols, 0xb7e30043 in ?? seems to imply that you are not inside a glibc function. Whatever, why focus on the EIP address? You say nothing about the instruction being executed. Don't think too much on a segfault trace, just stepi at the return from main, watch the registers, examine the assembly code and see what exactly happens. Besides, this question is probably best suited for StackOverflow (no pun intended) — xhienne
0xb7e30043 in ?? seems to imply that you are not inside a glibc function - How does the runtime knows I am not inside a glinc function? Does it looks some symbol table before each execution? — Filipe Rodrigues
I'm not sure, but I think the message doesn't say that it is a segfault to access that address, but that executing the code at that address causes a segfault. And this is very likely as you execute a random code without registers set accordingly. Or you have a byte offset to the actual opcode there and get a different opcode getting completely chaotic results. Did you look at the disassembler? — Philippos
@Philippos You are right! It is not that I could not jump to it, it that I could and one of the instructions are invalid. I`ll add some details in the answer. — Filipe Rodrigues

Filipe Rodrigues Filipe Rodrigues · Accepted Answer · 2017-10-06T06:32:19

The problem was that the instruction at 0xb7e30043 was invalid.

Here is the current instruction:

0xb7e30043: add    %cl,(%eax)

I looked into the eax value , and it is zero. From there, things are easier. The process tried to access memory at 0x0 and failed with a segfault.

Why does this program causes a segfault?

1 Answers