Format Strings

By Kurt Seifried (seifried@securityportal.com) for SecurityPortal

September 26, 2000 - Format string attacks have been possible for many years, but only recently have they received much public attention. As with buffer overflows, it is relatively easy for lazy/tired/busy/careless programmers to let a format string bug slip into an otherwise fine piece of software. Also as with buffer overflows, the attacker will try to slip data in that wasn't ever meant to be handled by the program (e.g.. a really long string, or a string containing specially formatted characters).

Between the ease of blackbox testing (poking closed source proprietary applications within a controlled environment) and source code review (upon which the majority of Unix systems rely) it is far from impossible for attackers to find exploitable bugs. Further proof of this is the relatively large number of format string bugs found in software packages recently, as people have started to look for them.

What Exactly is a Format String Attack?

Almost all programs take in some user input, process it, and then take an action based on the result. If proper care is not taken with the user supplied data, it is possible for an attacker to slip in special characters such as %n, %p, and %f. These characters can be positioned so that they overwrite certain memory locations, resulting in elevated privileges for the attacker (such as root). Unlike buffer overflows, where having more data then the size of your buffer is always a bad thing, there are some legitimate cases where these special characters need to be present for things to work right. This makes it slightly more difficult then solving the buffer overflow problem since you can't automatically "fix" every occurrence. In these cases, an actual source code review is needed. The good news is that finding these problems is relatively easy, and fixing them is not incredibly difficult. To quote Chris Evans (chris@scary.beasts.org):

Intro
Welcome to a short series of security bugs, all involving mistakes with "user supplied format strings". This class of bug is very popular on Bugtraq at the moment, so what an ideal time for a few examples.

BSD-lpr
If we look into lpr/lpd/printjob.c, we can find the following two lines of code
        if ((s = checkremote()))

                syslog(LOG_WARNING, s);
This is a classic format string mistake.
It may not be exploitable, because the failure strings returned by checkremote() in lpr/common_source/common.c, do not contain much data that a user could control.
However, it illustrates that format string bugs creep in everywhere, even in code that gets syslog() calls correct the majority of the time, as is the case with BSD-lpr.

Fix
OpenBSD ship BSD-lpr. Not only have they already fixed this in their CVS, but they also offer web indexed CVS. They caught it independently as part of their "format strings" audit.
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/lpr/lpd/printjob.c?r1=1.19&r2=1.20
...
...
The fix in OpenBSD boils down to:
-  syslog(LOG_WARNING, s); 

+   syslog(LOG_WARNING, "%s", s); 

Obviously, fixing these issues simply takes some time and effort expended in code auditing, a lot of which can be automated (grep anyone?) These problems are incredibly common and numerous. From CERT advisory 2000-13:

The wu-ftpd "site exec" vulnerability is the result of missing character-formatting argument in several function calls that implement the "site exec" command functionality. Normally if "site exec" is enabled, a user logged into an ftp server (including the 'ftp' or 'anonymous' user) may execute a restricted subset of quoted commands on the server itself. However, if a malicious user can pass character format strings consisting of carefully constructed *printf() conversion characters (%f, %p, %n, etc) while executing a "site exec" command, the ftp daemon may be tricked into executing arbitrary code as root. The "site exec" vulnerability appears to have been in the wu-ftpd code since the original wu-ftpd 2.0 came out in 1993. Any vendors who have based their own ftpd distributions on this vulnerable code are also likely to be vulnerable.

Since 1993. And people wonder why there are so many computer security incidents. The sad part is, that like buffer overflows, nobody (well nobody except for OpenBSD) will really deal with them as attackers find and use them, much less do a really solid code audit (like OpenBSD) and deny their use to attackers.

Almost every ftp server has been found to contain format string bugs, including OpenBSD's ftp. Most of these allowed for remote root compromise, in several cases via anonymous access. Even though many different code bases were involved, they all shared similar problems. This trend is similar to buffer overflows, which were first proposed several decades ago, and have been well known for many years, yet have cropped up dramatically in the last week (around a half dozen buffer overflows in popular software have been found and fixed, mostly after being used by attackers.)

Conclusion

It would seem that computer programmers are determined not to learn from mistakes made in the past, nor do the majority seem interested in fixing them once found. Thus we are doomed to repeat the failures over and over again ad infinitum. A quick look at the weekly Linux or BSD digest, for example, shows no real decline in the number of problems found, most of which fall in to a few main classes that are painfully well known.

The best way to fix this trend would be to educate programmers. Unfortunately, this doesn't seem to work too well, so the next best solution is to audit code (if you can) and submit patches. While it can be argued that authors of free software shouldn't have to do code audits (which are really not much fun - let's face it), there is an element of responsibility involved. If someone is going to write something that many people use and depend on, it should be done right.

SecurityPortal.com