Stack Smashing

StackSmashing is when an attacker purposely overflows a buffer on stack to get access to forbidden regions of computer memory. This is really bad. A stack smash is based upon these attributes of common implementations of C and C++:

A stack based language that stores data and return addresses on the same stack.
The language permits the program to write past the end of an array that is stored on the stack.
The language permits data on the stack to be executed.
- This is often a function of processors as well as languages--though a completely bugfree implementation of a completely type-safe language can prevent its runtime system from ever trying to execute pages on the stack (or other user-writeable pages); most OperatingSystems use the MMU as an additional safeguard; any attempt to execute user-writeable pages results in an exception; with a terminated process the usual result. The x86 architecture is a noticeable exception--it was designed with SelfModifyingCode as a requirement (lots of legacy DOS code that performs self-modification); therefore its MMU doesn't provide a way to disallow execute access to user-writeable pages. This was belatedly addressed in AMD's 64bit extensions.
The program being attacked has something the attacker wants -- typically root access.

The attacker delivers data to the application which the application stores in an array on the stack. The data is too large for the array, and the application does not check the length. The extra data is stored in other stack variables which are past the end of the array, up to and including the function's return address. The data which is shoved into the function's return address overwrites the real return address, substituting instead the address of the data. When the function returns, it returns not to its caller, but instead jumps directly to the malicious code on the stack, which can do anything that the program has permissions for.

The risks of StackSmashing attacks can be reduced by writing in a language that performs bounds checking on arrays and running daemons with restricted permissions. In a language like C, which does not perform bounds checking, you can use system calls to allocate a page to act as the buffer and deallocate the surrounding pages so that any attempt to read or write outside the buffer causes a hardware trap.

One of the earliest lessons in classes I taught to CeeLanguage students under my tutelage was that any input to a buffer that didn't explicitly have bounds checking (e.g. scanf()) was strengt verboten and any work submitted where this was detected was subject to grade penalties.

It wasn't about security in those days, just about really hard-to-catch bugs. Security was/is the happy by-product of such diligence.

Q: If I overflow the program's stack to kill the program, is that a stack smash?

A: No. Overflowing a program's stack as a denial of service attack is not a stack smash. A stack smash purposefully changes variables and internal language data structures that the deliverer of the data is not supposed to have access to. Also, a stack smash leaves the attacked programming running, at least for long enough to do the attacker's bidding.

Q: Is Java succeptible to stack smashing?

A: No, because (a) Java checks the bounds of array accesses (b) Java arrays are always allocated on the heap and (c) there is no way to write data of arbitrary length into primitive values on the Java stack.

Q: What kinds of programs get stack smashed?

A: Programs which process data received from the internet are especially vulnerable. Mail daemons are especially vulnerable, since they commonly run as root and process data of arbitrary length received from anyone on the internet. Sendmail is the canonical example of a vulnerable (and venerable) mail daemon.

Q: Does a program have to be recursive to be stack smashed?

A: No. It just has to not check the length of the data it received before storing it in a stack-based array.

Q: Are there stack smashing exploits that are specific to recursive programs?

Q: Why should I know about stack smashing? Don't only bad guys need to know about it?

A: If you don't know how it works, you can't protect your own systems against it.

Q: Will you teach me how to stack smash so I can break into systems?

A: No. Go away.

For a linux defense against stack-smashing attacks, check out StackGuard at http://immunix.org

-- JohnWatson

Be careful not to confuse StackSmashing with SmackStashing.