Vulnerabilities with Swish

[jtb () THEO2 PHYSIK UNI-STUTTGART DE (Jochen Thomas Bauer)]

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