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.
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.
If we look into lpr/lpd/printjob.c, we can find the following two lines of codeif ((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.
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.
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.)
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.