Next Previous Contents

13. Writing Secure Code

The ability to audit software for existing vulnerabilities, as well as preventing them from happening in code that you write, are important qualities to develop. There is a wealth of information available on the Internet to inform you of the type of vulnerabilities, and how they are created, as well as preventing your code from becomming a future vulnerability.

13.1 Preventing /tmp Exploits

On Monday, March 9, 1998, Rogier Wolff summarized on the linux-security@Red mailing list the issues with an exploit that has recently been found. By being able to predict a temporary filename that will be created in the world-writable directory /tmp, it may be possible for a user (especially files created by the root user) to unknowingly reveal confidential information about the system. He wrote:


Every now and then a new ``exploit'' turns up of some program that uses tmp files. The first solution was ``sticky bits'', but since links exist (that's a LONG time), that solution is inadequate.


The problem is that you put an object (link/pipe) in the place where you expect a program to put its tempfile, and wait for another user to open the tempfile. Usually a method can be found that would allow you to gain access to rights of the user opening the tempfile.

Sometimes a program already checks for the existence of the file, and creates it if its not there. This is not atomic, and cannot easily be made secure. The standard trick is to create a symlink that you move back and forth between the ``expected'' file name and some ``storage place''. On operating systems, like HPUX and SunOS, this has a much better than 50% chance of success because they have synchronous directory updates. On operating systems that have an efficient buffer cache, like Linux, the chances are much worse. But that won't save your machine from someone gaining root access: the bad guys simply write a program to try it 100 times.

The Unix philosophy is that things that should be easy also -=are=- easy. So, a program that has setuid rights might need to be careful not to give those rights away. A non-setuid program should not have to worry about buffer overruns (you can crash the program, wow!). It should similarly not have to worry about temporary files.


The discussion continued on stating that each of these solutions may have problems, but I don't believe there is one sure-fire solution to this problem yet.

You should be sure to use temporary filenames that are not easily guessable. The mktemp(1) and mkstemp(1) program exists to create a more secure temporary file.

13.2 References

There are quite a few documents out there that describe some procedures to write secure code.

Some of these links (Specifically the Microsoft one) was pulled from the recent bugtraq summary which can be found at My first Secure Programming section appeared in May, '98.

13.3 Preventing Buffer Overflows

Buffer overflows are an attempt at exploiting a bug in a software program that does not allocate enough space to store data in a buffer, then using this to write past the end of the buffer, on top of other memory space, outside of its normal stack area.

To quote Aleph 1 <>,

``smash the stack'' [C programming] n. On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address. This can produce some of the most insidious data-dependent bugs known to mankind.

You can find more information and the rest of this article at titled ``Smashing The Stack For Fun And Profit'' written by Aleph 1.

You can find a full description of the problem at titled ``How to Write Buffer Overflows''.

There is a fully indexed page of this information available at

Solar Designer, the well-known Linux kernel hacker, has several times provided secure solutions to otherwise non-secure issues. His secure-linux document and selection of kernel patches helps to prevent such things as:

His document also explains the drawbacks to using these patches. You can find the patch, and more information at

StackGuard, a library and compiler technique, attempts to minimize the effects of these problems by fixing it at the library level, rather than at the individual program source level, with only a minimal performace penalty. You can find more information on this at

Next Previous Contents