Couple of questions about format string vulnerabilities

[Master Blaster]

Hi everyone.

I just starting reading a white paper about the so-called "format string attacks". The paper, which can be found at http://julianor.tripod.com/bc/tn-usfs.pdf, is quite tricky for me. First of all it was written with the x86 architecture in mind. I'm, however, using a x86_64 system (Fedora 9) so I had to download the glibc-devel.i386 package and compile all the sample programs with the "-m32" switch.

And now for my problems: as you can see in the paper, the writer claims that by running the sample program with "%x %x %x %x" as it's invocation argument I can see the value of the local variable x (which is 1). In my case, however, this value appears only when I use five %x's. Why is that?

Moreover, I also noticed that for some reason every time I run the program x is loaded into a different memory address. Why is this? In the paper this address is fixed and doesn't change in between separate executions....

Thanks in advance.

[stevea]

b/c the way stacks are constructed and the way the automatics are allocated is NOT consistent across systems.

On an x86 (F8) I get "1" - at eight %x's !

I think the issue is far overblown. If you can execute a program and you can write to it's data space this is almost as powerful as making any system call with any argument you wish. Of course tihs does no harm unless you have privledge to do harm in the first place. You can't overwrite another process or the kernel not can you write to the proc tables. The issue is most with things like setuid programs that could be subverted with other's provledges.

[aagestrand]

The reason for your program being loaded in different memory locations is most likely due to a security feature called address-space randomization, in which the kernel tries to protect itself against buffer attacks by randomizing the location of in-memory components. This is to stop attackers from utilizing a fixed offset to target vulnerable locations in memory. As always, there's a way around it. Sigh.

I seem to recall this is a kernel setting and that you can turn it off by using sysctl.