[8489] in bugtraq
No subject found in mail header
daemon@ATHENA.MIT.EDU (Jochen Thomas Bauer)
Tue Nov 10 16:58:35 1998
Date: Tue, 10 Nov 1998 16:01:11 +0100
Reply-To: Jochen Thomas Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
From: Jochen Thomas Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
To: BUGTRAQ@NETSPACE.ORG
On Tue Nov 10 10:19:31 1998, Aaron Campbell wrote
>You've made a pretty bold assumption here on what order the compiler will
>decide the local variables should live on the stack. In particular, any
>optimization options passed to gcc will often rearrange the positions of
>the automatic variables.
Thanks for pointing this out to me. I have made a little "experiment" on that
issue: I took the xlock.c file and compiled it with gcc-2.7.2.1 using the -S
option (gcc -S xlock.c) on my Linux PC. Although there are (of course) some
"..... undeclared" errors at lines 3269 and 3275 (that is NOT in the
function read_plan ) an output file xlock.s containing the assembler code is
produced. One can now see that if no optimizing options are used "char *home"
is located right above "char buf[121]" on the stack, but when you use the
-O or -O2 options with gcc then "FILE *planf" will be right above
"char buf[121]" on the stack. Therefore, in the latter case the most
significant byte (on a little endian machine) of "FILE *planf" will be
overwritten by NULL.
As Thomas Schweikle <tschweik@fiducia.de> has pointed out in his reply, there
may be some more "scenarios", depending on the architecture/compiler/options
combination used to compile xlock, so the question is if there is any
combination of architecture/compiler/options that will produce code
that contains a security hole.
Jochen Bauer
Institute for Theoretical Physics
University of Stuttgart, Germany
