stack protector only aborts in 99.5%

Lasse Kliemann lasse-hlfs-2008 at mail.plastictree.net
Sat May 10 11:56:47 PDT 2008


* Message by -Petr Cerny- from Tue 2008-05-06:
> Lasse Kliemann wrote:
> > Compiled with 
> >   gcc -U_FORTIFY_SOURCE overflow.c -o overflow
> > and invoked this way:
> >   ./overflow 10 > out 2>&1
> > 
> > The file `out' is then examined. A success is if it contains the string 
> > 'Aborted' and not the string 'segmentation fault' (case-insensitive). I did 
> > several 10.000 runs, and in some cases (no more then 0.5%), the outcome is 
> > *not* a success. But instead, the file `out' contains the output of the 
> > program, i.e., 0000000000.
> > 
> > Is this the expected behavior? Could it become a problem?
> > 
> > What could I try to track this down further?
> 
> It might be you are experiencing something I have seen on 64bit systems 
> (see the "tests in 5.9. cocoon toolchain" thread from Feb 2008). The 
> problem might be some stack alignment due to ABI.

Tests are run on an Intel Xeon, but as far as i see with a 32 bit OS.


> Things you may want to try:
> 
> 1) smash the stack with longer string (e.g. 20 bytes).

Just a few byte more have a great effect. I changed the call to strncpy:

(void)strncpy(b, "00000000000000000000", len);

Now, ./overflow 10 gives the same behavior as before, i.e, the stack 
protector kicks in only in about 99.5% of the runs. However, with ./overflow 11
the number of successes increases to about 99.9975% (tested with 200000 runs).

I could not show a single failure with ./overflow 12 or ./overflow 13.

Can a statement be made like this: if the stack protector does not abort the 
program, then the stack actually wasn't touched, although the buffer 
overflowed? This would most likely mean that the observed behavior does not 
pose a security problem.

> 2) disassembling the binary (gdb command 'disassemble') might give you 
> some clues - there would be some "unexpected" arithmetics with the stack 
> pointer (instead fo plain 'push') or similar.

I'm afraid that's beyond my expertise right now. :-)

I could post the output of that command, provided I find the time 
to install gdb.

Lasse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080510/fc2833c3/attachment.sig>


More information about the hlfs-dev mailing list