Hi LQ,

Actually following a security course, i was looking for more info regarding buffer overflow.

During my personal research, i've found something quite strange which is obviously due to my lack of knowledge.

Why are they some differents version of gcc not working the same way when memory allocating ?

let's take an simple example :

char tableau[5]
char tableau[10]

When disassembling this code with gdb, i do have the following :

On debian 4.x ( kernel 2.6 ) and gcc 4.1.2,
it does allocate 16 bytes for the two arrays
SUB $ 0x10, %esp

On debian 3.1 ( kernel 2.4 ) and gcc 3.4.6
it does allocate 40 bytes
SUB $ 0x28, %esp

I presume there are differences between both version of gcc and / or kernel.
I've tried to have a look within GCC online doc, but without success at the moment.

Can someone set me out on the path of truth ?

I've read some stuff regarding protected kernel mode ( which, as far as i understood,is activated in 2.6 kernel ) .. could it be a clue ?

Thanks for any infos.
Regards,
Pierre

Have you tried asking on gcc mailing list ?

Good idea.
i'll be back with an answer if i do have one on gcc mailing list.
Thanks.

What do you mean by "allocate"? It looks like you're "allocating" on the stack and not actually allocating heap memory.
ta0kira

What do you mean by "allocate"?
This is a misused term. My fault.
I mean that i was looking at the code doing gdb and disassembling it gave me a value substracted from %esp. ( which i understood as allocated )

To be as clear as possible, i was looking at the following link with the aim of studying a simple case of buffer overflow.

It does sound kind of like nitpicking, but the difference between stack and heap is relevant to your question. A heap allocation would normally be 8-byte aligned with glibc with a 12-byte header for each memory segment, if I remember correctly. Allocating it on the stack (I suppose your usage is correct) might align to the register size, might align to single bytes, or might do something entirely differently. I'll take a look at the link when I get a chance.
ta0kira

Alignment of stack allocations in gcc are made to comply with the -mpreferred-stack-boundary (which defaults to 16), but that is not the issure here. The issue is that gcc4 is more efficient about stack-allocation than gcc3 (which is a known phenomenon), and any naïve (as in hardcoding the stack location) buffer-overflow exploit for gcc3 code will need to be modified for gcc4 code.