Uncontrolled format string: Difference between revisions

Revision as of 10:01, 15 July 2018

Revision as of 17:44, 10 September 2018

Line 6:

This is a common vulnerability because format bugs were previously thought harmless and resulted in vulnerabilities in many common tools. [[Mitre Corporation|MITRE's]] CVE project lists roughly 500 vulnerable programs as of June 2007, and a trend analysis ranks it the 9th most-reported vulnerability type between 2001 and 2006.<ref>{{cite web|url=http://cwe.mitre.org/documents/vuln-trends/index.html |title=Vulnerability Type Distributions in CVE |date=May 22, 2007}}</ref>

Format string bugs most commonly appear when a programmer wishes to printoutput a string containing user supplied data (either to a file, to a buffer, or to the user). The programmer may mistakenly write <code>printf(buffer)</code> instead of <code>printf("%s", buffer)</code>. The first version interprets <code>buffer</code> as a format string, and parses any formatting instructions it may contain. The second version simply prints a string to the screen, as the programmer intended. Both versions behave identically in the absence of format specifiers in the string, which makes it easy for the mistake to go unnoticed by the developer.

Format bugs arise because C's argument passing conventions are not [[Type safety|type-safe]]. In particular, the <code>[[stdarg.h|varargs]]</code> mechanism allows [[Subprogram|functions]] to accept any number of arguments (e.g. <code>printf</code>) by "popping" as many [[argument]]s off the [[call stack]] as they wish, trusting the early arguments to indicate how many additional arguments are to be popped, and of what types.

Line 15:

Format bugs were first noted in 1989 by the [[fuzz testing]] work done at the University of Wisconsin, which discovered an "interaction effect" in the [[C shell]] (csh) between its [[command history]] mechanism and an error routine that assumed safe string input.<ref>{{cite journal |url=ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf |title=An Empirical Study of the Reliability of UNIX Utilities |first1=Barton P. |last1=Miller |first2=Lars |last2=Fredriksen |first3=Bryan |last3=So |journal=[[Communications of the ACM]] |volume=33 |number=12 |date=December 1990 <!--NB: paper copyright is 1989 --> |doi=10.1145/96267.96279 |pages=32–44}}</ref>

The use of format string bugs as an [[Vector (malware)|attack vector]] was discovered in September 1999 by [[Tymm Twillman]] during a [[security audit]] of the [[ProFTPD]] daemon <ref name="Tymm_proftpd" />. The audit uncovered an <code>[[snprintf]]</code> that directly passed user-generated data without a format string. Extensive tests with contrived arguments to printf-style functions showed that use of this for privilege escalation was possible. This led to the first posting in September 1999 on the [[Bugtraq]] mailing list regarding this class of vulnerabilities, including a basic exploit.<ref name="Tymm_proftpd">[http://seclists.org/bugtraq/1999/Sep/0328.html Bugtraq: Exploit for proftpd 1.2.0pre6]</ref> It was still several months, however, before the security community became aware of the full dangers of format string vulnerabilities as exploits for other software using this method began to surface. The first exploits leadingthat brought the issue to successfulcommon awareness (by providing remote root access [[privilegevia escalation]]code attackexecution) were published simultaneously on the [[Bugtraq]] list in June 2000 by [[Przemysław Frasunek]]<ref>[http://marc.theaimsgroup.com/?l=bugtraq&m=96179429114160&w=2 'WUFTPD 2.6.0 remote root exploit' - MARC]</ref> and the person using nickname ''tf8''.<ref>[http://marc.theaimsgroup.com/?l=bugtraq&m=96171893218000&w=2 'WuFTPD: Providing *remote* root since at least1994' - MARC]</ref> The seminal paper "Format String Attacks"<ref>[http://seclists.org/bugtraq/2000/Sep/0214.html Bugtraq: Format String Attacks]</ref> by [[Tim Newsham]] was published in September 2000 and other detailed technical explanation papers were published in September 2001 such as ''Exploiting Format String Vulnerabilities'', by team [[TESO (Austrian hacker group)|Teso]]<ref name="team_teso"/>.

== Compilers Prevention ==

Line 22:

Most of these are only useful for detecting bad format strings that are known at compile-time. If the format string may come from the user or from a source external to the application, the application must validate the format string before using it. Care must also be taken if the application generates or selects format strings on the fly. If the GNU C library is used, the <code>-D_FORTIFY_SOURCE=2</code> parameter can be used to detect certain types of attacks occurring at run-time. The <code>-Wformat-nonliteral</code> check is more stringent.

== Detection in x86-compiled binaries ==

Contrary to many other security issues, the root cause of format string vulnerabilities is relatively easily detectable in x86-compiled executables: For <code>printf</code>-family functions, proper use implies a separate argument for the format string and the arguments to be formatted. Faulty uses of such functions can be spotted by simply counting

the number of arguments passed to the function; an 'argument deficiency'<ref name="team_teso"/> is then a strong indicator that the function was misused. Counting the number of arguments is often made easy on x86 due to a calling convention where the caller removes the arguments that were pushed onto the stack by adding to the stack pointer after the call, so a simple examination of the stack correction yields the number of arguments passed to the <code>printf</code>-family function.

==See also==