What's New!

Chat with

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 


Meet the 
Happy Hacksters 

Help for 



It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

More on C Programming...

How to Program C Securely

Probably the largest class of computer break-in techniques is C programs running on Unix type operating systems that suffer from buffer overflows.

Even if you are just beginning to learn how to program in C, it may be wise to get an early understanding of this major weakness in the language.

Is your goal to break into computers? The single most important thing about C is that it allows buffer overflows. "Segmentation fault," anyone?;^) OK, OK, you nitpickers, I know not all buffer overflows cause a "segmentation fault" error messages, but give me a break, I'm trying to make this guide funny. Trust me on this, there will be days when you will need every bit of humor you can muster to endure sorting out why your C program won't compile.

Newbie note: Buffer overflow? Here's the easy explanation. A buffer is a place in memory where data is briefly stored while a program is running. A buffer overflow is when a program tries to put data into a place in the victim computer's memory where there isn't enough room for it. It's like pouring two liters of water into a one liter container. The extra water overflows. If data that overflows a buffer in a C program contains the right commands, and if it leaks into the right place, voila! You get a root shell!

Here's the technical explanation of a buffer overflow exploit. A buffer is a contiguous block of computer memory that, while a program is running, holds a given type of data. The problem comes with "dynamically allocated variables" (a variable is a name in a program that holds data that may vary). In order to not use up too much memory, a program with dynamically allocated variables does not decide how much memory to give to these variables until it is already running.

What happens if a program pours too much data into this dynamically allocated buffer? It overflows, leaking out somewhere else. A buffer overflow exploit uses this leaking data to put assembly language code elsewhere into the victim computer's memory -- often somewhere that willcreate a root shell.

The C programming language allows buffer overflow exploits because some of its functions for copying or appending strings fail to check whether doing so would overflow a buffer. These include sprintf(), strcat(), strcpy(), and vsprintf().

A buffer overflow alone is not enough to take over a computer. It must be in a program that would send the overflow to a location that would enable it to run a command to create a shell with root privileges. Then an exploit program must be run that will pour into that buffer the exact number of bits needed to insert these instructions, which may be in assembly language, into the right memory location.

Assembly languages are the commands that the central processing units (CPU) of computers understand. Because there are many different kinds of CPUs (SPARCs for Suns, MIPS for SGIs etc.), you may have to make sure the exploit you want to run will work on that kind of CPU.

Wizard tip: Do you want to become an Uberhacker? Do you want to become one of those almost mythological beings who are said to flow through cyberspace as if there were no walls? Write your own buffer overflow exploits! For a detailed explanation of how to search for these security holes and design code to exploit them, see "Smashing the Stack," by Aleph One.Better yet, don't write buffer overflow exploits. As my secret super hacker friend says, "Overflows have become annoying. Since the screen exploit for
Linux (almost 3 years ago) that's most of what's been coming out. It's boring! It's the same damn bug over and over again. WE GET THE POINT ALREADY! Seriously, if someone came up with
three overflow bugs and someone else came up with 1 on-overflow root exploit, I'd have more respect for the second person."

It can be embarrassing, however, if you are the programmer who writes software that someone else uses to create a buffer overflow exploit. How can you learn to write C code that avoids this nasty problem? Aleph One <aleph1@DFW.NET>, who runs the Bugtraq computer security list, has come up with a list of references for those of us who want to learn how to write secure C code. (Our apologies if these links go out of date.)


Chapter 22 in the book Practical UNIX & Internet Security by Simson Garfinkel, Gene Spafford (O'Reilly & Associates, 1996) is called "Writing Secure SUID and Network Programs".
Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs, by Steve Maguire, (Microsoft Press, 1993). The book focuses on writing bug-free software.
Take the SANS course "Writing Secure Programs," taught by Matt Bishop.


Honest, C programming really is easy and fun. You just have to have the ability to look at it as an adventure when your !@#$@##$% program doesn't compile! Joker can tell you that's true, right, Joker?:^)

You can go to jail warning: It is illegal to break into a computer even if you do no harm. The only Uberhackers I know of are so talented, and also so careful to do no harm, that only another Uberhacker would ever know one had broken into a computer. But if you are reading this to find out how to break into computers, you probably aren't good enough to keep from getting caught. Leshka's sendmail exploit program only does a tiny bit of cleanup, so you still are likely to get caught if you run it against a computer whose owner has not given you permission to break in. You also are likely to accidentally do damage while root on the victim computer. Do this to your own computer so you are the one who has to figure out what you did as root, OK?

Carolyn's most
popular book,
in 4th edition now!
For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Visit this group

Return to the index of Guides to (mostly) Harmless Hacking!

 © 2013 Happy Hacker All rights reserved.