Emily's Coding Corner

Before we start with the real stuff, there's a bunch of good advice that applies to programming in general, but which bears repeating in a security context.

Always check return values

Yes, even if you know this and that system call cannot fail, check the return value. Sometimes, even the calls that cannot will fail, and bite you.^11.1

Fail-open vs. fail-closed

Consider the following piece of code in a setuid root program:

        /* Drop privilege */
        pwd = getpwnam("nobody");
        if (pwd != NULL) {
                setgid(pwd->pw_gid);
                setuid(pwd->pw_uid);
        }

Normally, this works as intended, because there's of course a nobody user defined in your password database. However, an attacker may be able to make the getpwnam call fail nevertheless (e.g. by lowering certain resource limits before calling your application). This is a typical case of fail-open code, i.e. if a portion of code fails, the application is ``opened'' to abuse.

The opposite is of course fail-closed; when something fails unexpectedly, the application remains ``closed.'' In the code snipped above, a fail-closed solution would be to abort the program when it is unable to find information on the nobody user.

A variation of that theme is the use of a whitelist instead of a blacklist when weeding out potentially dangerous things such as characters, or network clients. A blacklist is a typical fail-open solution; if you forget one dangerous character, your application is toast. Using a whitelist is much safer; if you forget one harmless character, you may have bad feedback from your beta testers, but you're not exposing your users to a security risk.

Don't do memory bugs

Seasoned programmers usually have developed reasonable skills at avoiding memory allocation problems to a certain degree. However in security critical code, you should check twice all your memory management and access is right. This doesn't apply just to buffer overflows; messing up heap memory used by malloc can be exploitable as well.