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 <tschweikat_private> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:22:32 PDT