Dillema with buffer overflow

Question

I'm playing with one stack overflow example. This example looks like this:

 void return_input (void){ 
    char array[30];    
    gets (array); 
    printf("%s\n", array); 

 }

 main() { 
    return_input();    
    return 0;    
 }

All this code is in the file called overflow.c. We have vulnerable function called return_input, particularly it's 30 byte char array. I compiled it and opened vulnerable function in gdb and got following output:

 (gdb) disas return_input
 0x08048464 <+0>:   push   %ebp
 0x08048465 <+1>:   mov    %esp,%ebp
 0x08048467 <+3>:   sub    $0x48,%esp
 0x0804846a <+6>:   mov    %gs:0x14,%eax
 0x08048470 <+12>:  mov    %eax,-0xc(%ebp)
 0x08048473 <+15>:  xor    %eax,%eax
 0x08048475 <+17>:  lea    -0x2a(%ebp),%eax
 0x08048478 <+20>:  mov    %eax,(%esp)
 0x0804847b <+23>:  call   0x8048360 <gets@plt>
 0x08048480 <+28>:  lea    -0x2a(%ebp),%eax
 0x08048483 <+31>:  mov    %eax,(%esp)
 0x08048486 <+34>:  call   0x8048380 <puts@plt>
 0x0804848b <+39>:  mov    -0xc(%ebp),%eax
 0x0804848e <+42>:  xor    %gs:0x14,%eax
 0x08048495 <+49>:  je     0x804849c <return_input+56>
 0x08048497 <+51>:  call   0x8048370 <__stack_chk_fail@plt>
 0x0804849c <+56>:  leave  
 0x0804849d <+57>:  ret    
 End of assembler dump.

As you see from the function prologue we reserved hex48(dec 72) bytes on the stack for local variables. First I was trying to find the address where our vulnerable array starts on the stack. I think it's -0x2a(%ebp), am I right? Hex2a is 42 decimal. As I understand it means that we can write safely 42 bytes before we start to overwrite EBP saved on the stack. But when I run this example it's enough to right only 37 bytes to get segmentation fault:

rustam@rustam-laptop:~/temp/ELF_reader$ ./overflow
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)

How is 37 bytes enough to overflow buffer? If our local char array is -42 bytes from saved EBP

Answer 1

It is hard to tell without seeing the whole disassembly of the function.

However, my guess is that the %gs:0x14 stored at -0xc(%ebp) may be your stack canary that causes a clean exit if a stack coruption is detected. So this value is stored at -0xc(%ebp), which means that your buffer is in fact only 30 bytes large, followed by whatever comes after.