Issue No. 06 - November/December (2005 vol. 3)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MSP.2005.151
My husband is a software engineer and reads IEEE Security & Privacy magazine faithfully. Hence, copies are frequently lying throughout the house. I don't know if you or your editorial staff have children, but I hope you can understand what a keen disappointment it is to a five-year-old boy to find a magazine with "cool toys" on the cover [Sept./Oct.], only to open it up and find "boring words and stuff" inside. He suggests if you continue to place toys on your cover that you could at least have a page or two dedicated to them. Thanks to IEEE Security & Privacy, John now knows the bitter, age-old truth: You can't judge a book (or periodical) by its cover.
Thanks for the letter, Loris. Apparently our efforts to target young software engineers worked too well! —Eds.
Beyond Stack Smashing
In the article "Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns" ( IEEE Security & Privacy, vol. 2, no. 4, 2004, pp. 20–27), the examples in Figure 2 are not entirely correct.
As we know, depending on the implementation, the stack will either grow down (toward lower memory addresses—from FFFFFFFF toward 00000000 for example), or up. Growing down is the way the stack grows on many computers, including Intel, Motorola, SPARC, and MIPS processors.
In the growing down mechanism, the overflowing buffer will change the contents of addresses that are higher than the buffer's address, that is, the variables before the buffer, stack frame pointer, return address, and so on, but not the variables after the buffer.
I ran the example in the article's Figure 2 and also generated assembly code. Both of them prove the above. [To see this assembly code, go to www.computer.org/portal/pages/security/v3n6/letters.xml.]
According to the example in Figure 2a, the function pointer f will be modified if there is a buffer overrun so that the exploit can be carried out using f, but the fact is that the variable defined in the order as in Figure 2a will not modify the function pointer even if there is a buffer overrun, and so there will not be an exploit.
As we pointed out, actual implementation of these exploits depends on details of how specific compilers lay out local variables and parameters. The letter addresses the case in which the assumption about local variable layout that we called out in our description of Figure 2 does not hold; recent versions of compilers such as Microsoft Visual C++ perform "variable reordering" to cut down the likelihood that buffer overruns will be exploitable via pointer subterfuge techniques. The references we discussed in the sidebar go through these and other complications in great detail (including the impact mentioned in the letter of stack growth direction on stack smashing and arc-injection attacks), and are important reading for anybody who wants to reduce these exploits to practice. —Jon Pincus and Brandon Baker