Very Computer

Hey,

I'm a novice programmer reading up on buffer overflows in order to secure
my own programs for exploitation. While reading over "Smashing The Stack
For Fun And Profit" (from phrack #49) i came accross the following
discrepancy on a standard workstation install of redhat 7.2 (gcc 2.96): I
complile this:

example1.c:
------------------------------------------------------------------------------
void function(int a, int b, int c) {
   char buffer1[5];
   char buffer2[10];

Quote:}
}

void main() {
  function(1,2,3);

Quote:}

------------------------------------------------------------------------------

with gcc -S -o example1.s example1.c

and instead of

        pushl %ebp
        movl %esp,%ebp
        subl $20,%esp

i have

        pushl   %ebp
        movl    %esp, %ebp
        subl    $40, %esp

under the function call. My question is: Why? Is this something redhat
specific? is this something gcc specific? is this the standard on most
linux (or even *nix) systems? I realise the article is a bit dated, but
having a buffer double the size caught be off guard.

Your insight would be greatly appreciated, Thanks. :)

Doesn't even compile, and if I remove the extra } I still get a
warning about main. For this particular example main is actually
of no interest at all, we could as well remove it.

Quote:> ------------------------------------------------------------------------------

> with gcc -S -o example1.s example1.c

> and instead of

>         pushl %ebp
>         movl %esp,%ebp
>         subl $20,%esp

> i have

>         pushl   %ebp
>         movl    %esp, %ebp
>         subl    $40, %esp

Looks like each array is rounded up to a multiple of 16 bytes,
and finally 8 bytes is added. That might be done to align the
arrays on cacheline boundaries and that way get a better
performance. But does it actually keep *all* stackframes
cacheline aligned?

--
Kasper Dupont -- der bruger for meget tid p? usenet.

2.96 is a beta and should not be used for anything and is probably the
reason for your weirdness in compileing

and yes redhat shipped a beta c compiler aren't they stupid

Bullshit. You obviously never used it.

--
Hal Burgiss

Quote:> Bullshit. You obviously never used it.

it's quite interesting that they haven't even got the 2.96 gcc compiler on
GNUs gcc homepage, which pretty much states that it was a beta.
http://www.gnu.org/software/gcc/releases.html

/svek

Sure it was a beta, but redhat chose to use it because it was STILL better
than anything available at the time (especially to support archs other than
x86).

--

Computer System Administrator   http://www.math.unl.edu/~rdieter/
Mathematics and Statistics              
University of Nebraska Lincoln

...and the facts it broke C++ library compatibility through use of a dodgy
ABI, and wasn't able to compile a kernel properly doesn't really enter into
it?

In their defence, at least they provided kgcc as a fall-back...

~Tim
--

and the river flowed                        |http://spodzone.org.uk/

Quote:> Sure it was a beta, but redhat chose to use it because it was STILL
> better than anything available at the time (especially to support
> archs other than x86).

I don't judge redhat, they probably had their reasons but in my opinion one
should use stable software in a stable release.
but then again that is one of the reasons I don't use redhat.

/svek

hogwash.  The same could be said of gcc-3.0 and gcc-3.1.

Quote:> and wasn't able to compile a kernel properly doesn't really enter
> into it?
> In their defence, at least they provided kgcc as a fall-back...

In redhat 7.0 this was true, but that is ancient history by now, and no
longer true.

--

Computer System Administrator   http://www.math.unl.edu/~rdieter/
Mathematics and Statistics              
University of Nebraska Lincoln

IMO, gcc-2.96 (at least in its current incarnation in rh7.3) is quite
stable...though people's critera for this vary.  I consider it's better
support for c++ standards a big plus...

--

Computer System Administrator   http://www.math.unl.edu/~rdieter/
Mathematics and Statistics              
University of Nebraska Lincoln

Yes, that's deliberate, and only to be expected - see, those "3"s there are
what's called a "version number", right?
But that's a very different thing compared to taking something flagged as
beta, where incompatibilities are known to be rife, and pushing it out as
your primary compiler on a so-called "stable" distribution.

`Hogwash', my ass.

~Tim
--

The apple must fall to the ground           |http://spodzone.org.uk/

Historically, every gcc revision has had c++/libstc++/abi incompatibilies:
gcc 2.58 -> gcc 2.6 -> gcc 2.7 -> egcs (2.91?)-> gcc 295 -> gcc 296 ->
gcc3.0 -> gcc3.1.  I see no real difference for the gcc296 case.

--

Computer System Administrator   http://www.math.unl.edu/~rdieter/
Mathematics and Statistics              
University of Nebraska Lincoln

Well, following this advice I have upgraded gcc to 3.1, and low and
behold, nothing! I still get the compiler giving the size of 40 bytes
instead of 20, my question stands: Is this standard on most linux
computers or not?

Thanks :)

Padding data structures for byte/word alignment is a common compiler
optimization.

--

Computer System Administrator   http://www.math.unl.edu/~rdieter/
Mathematics and Statistics              
University of Nebraska Lincoln

Only interesting as FUD ammo. It is obviously not supported by them, so
no reason to be listed as a supported release. But is supported by Redhat,
so if you want to find compilers supported by Redhat, you can go
whereever on redhat.com, and I am sure you will find it. Now if you want
to use it on non-redhat system, you have a tough choice to make,
assuming you want/need support. Otherwise, it is a non-issue.

Have I missed something in the GPL that says improving on someone elses
work is a bad idea? Especially since they put this out there, some gcc
bugs were found sooner than they might have been otherwise, which were
fed back to gcc development.

As to questions of quality, you will have a hard time convincing me,
unless you've used it more:

    518

And its been a long, long time, since anything I've built had any kind
of problem that might be traceable to compiler misbehavior.

Quote:> beta. http://www.gnu.org/software/gcc/releases.html

> /svek

--
Hal Burgiss