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.
/tmp Exploits
On Monday, March 9, 1998, Rogier Wolff
[email protected]
summarized on the
linux-security@Red Hat.com 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.
/tmp directory, that's private for every userid. 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.
There are quite a few documents out there that describe some procedures to write secure code.
setuid programs and
other documents from him on writing secure code
http://seclab.cs.ucdavis.edu/~bishop/secprog.html Some
of that goes back to 1986 -- Whew.
setuid
programs.Some of these links (Specifically the Microsoft one) was pulled from the recent bugtraq summary which can be found at http://geek-girl.com/bugtraq/1998_3/0215.html My first Secure Programming section appeared in May, '98.
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 <[email protected]>,
``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 http://www.2600.com/phrack/p49-14.html titled ``Smashing The Stack For Fun And Profit'' written by Aleph 1.
You can find a full description of the problem at http://l0pht.com/advisories/bufero.html titled ``How to Write Buffer Overflows''.
There is a fully indexed page of this information available at http://reality.sgi.com/nate/machines/security/
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:
/tmp, which prevents non-root users from
creating hard links to files they don't own.
/tmp, which disallows writing to
pipes not owned by the user in directories with sticky bit set.
/proc prevents non-root users from seeing
statistics for processess other than their own, as well as making
information about existing network connections unavailable.His document also explains the drawbacks to using these patches. You can find the patch, and more information at http://www.false.com/security/linux/index.html.
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 http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/