I'm taking a class for Security+ certification. Today one of the topics we covered was buffer overflows. The textbook explanation was confusing. For that matter I think it was wrong, but I was so confused by the end that I'm not sure.

I'm going to give a simplified example and explanation of a buffer overflow, similar to the one I gave to the instructor, and then to the class.

I drew a diagram on the board of a very simple program. It occupied a single continuous area of memory, divided into three blocks. The top and bottom blocks contained code, while the block somewhere in the middle contained data.

This is an especially bad design, because if you pass the program more data than the data block can hold, you overwrite the code in the bottom block.

That's precisely what a buffer overflow does. Someone wanting to exploit this writes a program that does something bad--perhaps changing the administrator or root password, installing some other software, scrambling data, or formatting a hard drive--and then determines the size of that data buffer. The person then passes that exact amount of data to the program, plus the bad-guy code he wants the system to run.

The bad-guy code overwrites some of the original program's code, so when the program gets to those instructions, instead of doing what it's supposed to do, it runs the bad-guy code instead.

Modern compilers and programming techniques make buffer overflow vulnerabilities a lot rarer than they used to be, but they still happen sometimes. I know that at least once in the last two years, Microsoft had to recall and reissue one of its monthly hotfixes because the hotfix had a buffer overflow vulnerability in it. So at least in theory, a system was more secure without that patch than it was with it. (I had fun trying to explain that to the higher-ups.) So they aren't unheard of.

The textbook gave several remedies to prevent buffer overflows: Use firewalls, disable all unnecessary services and software, and keep all the latest security patches applied (which works unless the patches themselves are flawed).

My favorite remedy, though, is to try not to put Intel/AMD x86 boxes directly on the Internet if I can avoid it. Although many commercial firewalls these days are x86-based, the ideal firewall uses something else. And whenever possible, run things like mail, DNS, and other things that anyone can access on something other than x86. If your client demands Exchange, that's fine. Just set up a Linux box running on something weird (an old PowerPC Macintosh is a good choice, but if you want something newer and more reliable, a Sony Playstation 3 would work well) and configure its SMTP server to forward everything to your Exchange server running inside the firewall.

Yes, I'm saying there's a role in your enterprise for Sony Playstation 3 videogame consoles.

When a script kiddie tries to pass an Intel buffer overflow to a different CPU architecture, the results will be unpredictable, but I can guarantee the overflow won't do what the script kiddie intends, since the Intel instructions are gibberish to a PowerPC or MIPS or ARM or Alpha CPU.

So that's what a buffer overflow is, and a few textbook answers about how to deal with them, plus a real-world solution that isn't likely to find its way into any books any time soon.