Uncontrolled format string: Difference between revisions

Content deleted Content added
m See also: rm duplicated links
m Reverted edit by 2402:8100:27A0:F555:D411:D1FF:FE3B:1F32 (talk) to last version by InternetArchiveBot
 
(155 intermediate revisions by more than 100 users not shown)
Line 1:
{{Short description|Type of software vulnerability}}
'''Format string attacks''' are a class of [[Exploit_(computer_science)|vulnerabilities]] discovered in [[June 2000]] by [[Przemys&#322;aw Frasunek]] and [[tf8]], previously thought to be harmless. The first exploit which used the new technique allowed an attacker to gain remote root privileges on [[wu-ftpd]] 2.6.0. Format string attacks can be used to [[Crash_(computing)|crash]] a program or to execute harmful code. The problem stems from the use of unfiltered user input as the format string parameter in certain [[C_programming_language|C]] functions that perform formatting, such as <code>[[Printf|printf()]]</code>. A malicious user may use the %s and %x format tokens, among others, to print data from the stack or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the %n format token, which commands <code>printf()</code> and similar functions to write back the number of bytes formatted to an argument of [[Datatype|type]] int&nbsp;*. By manipulating the stack by using spurious format tokens, this argument can be faked as part of the format string or possibly other user input.
{{Use dmy dates|date=August 2019|cs1-dates=y}}
'''FormatUncontrolled stringformat attacksstring''' areis a classtype of [[Exploit_(computer_science)|vulnerabilities]]code discovered in [[June 2000injection]] by [[Przemys&#322;awsoftware Frasunekvulnerability|vulnerability]] anddiscovered [[tf8]],around previously1989 thoughtthat tocan be harmless.used Thein first[[security exploit]]s.<ref whichname="CWE134"/> usedOriginally thethought newharmless, technique allowed an attacker to gain remote root privileges on [[wu-ftpd]] 2.6.0. Formatformat string attacksexploits can be used to [[Crash_Crash (computing)|crash]] a program or to execute harmful code. The problem stems from the use of unfiltered[[unchecked user input]] as the [[format string]] parameter in certain [[C_programming_languageC (programming language)|C]] functions that perform formatting, such as <code>[[Printf|printf()]]</code>. A malicious user may use the <code>%s</code> and <code>%x</code> format tokens, among others, to print data from the [[call stack]] or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the <code>%n</code> format token, which commands <code>printf()</code> and similar functions to write back the number of bytes formatted to an argumentaddress ofstored [[Datatype|type]] int&nbsp;*. By manipulatingon the stack by using spurious format tokens, this argument can be faked as part of the format string or possibly other user input.
 
==Details==
This is a common vulnerability due to the fact that format bugs were previously thought harmless and resulted in vulnerabilites in many common tools. [http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string MITRE's CVE project] lists roughly 150 vulnerable programs.
A typical exploit uses a combination of these techniques to take control of the [[instruction pointer]] (IP) of a process,<ref name="team_teso"/> for example by forcing a program to overwrite the address of a library function or the return address on the stack with a pointer to some malicious [[shellcode]]. The padding parameters to format specifiers are used to control the number of bytes output and the <code>%x</code> token is used to pop bytes from the stack until the beginning of the format string itself is reached. The start of the format string is crafted to contain the address that the <code>%n</code> format token can then overwrite with the address of the malicious code to execute.
 
This is a common vulnerability because format bugs were previously thought harmless and resulted in vulnerabilities in many common tools. [[Mitre Corporation|MITRE's]] [[Common Vulnerabilities and Exposures|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 name="Trends"/>
Format string bugs most commonly appear when a programmer wishes to print a string containing user supplied data. 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.
 
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 [[Type safety|type-unsafe]]. In particular, the <code>varargs</code> mechanism allows [[Subprogram|functions]] to accept any number of arguments (e.g. <code>printf</code>) by "popping" as many [[Parameter|arguments]] off the call [[Stack_(computing)|stack]] as they wish, trusting the early arguments to indicate how many additional arguments are to be popped, and of what types.
 
Format bugs arise because C's argument passing conventions are not [[Type safety|type-unsafesafe]]. In particular, the <code>varargs[[vararg]]s</code> mechanism allows [[Subprogramsubprogram|functionsfunction]]s to accept any number of arguments (e.g. <code>printf</code>) by "popping" as many [[Parameter|argumentsargument]]s off the [[call [[Stack_(computing)|stack]] as they wish, trusting the early arguments to indicate how many additional arguments are to be popped, and of what types.
 
Format string bugs can occur in other programming languages besides C, such as Perl, although they appear with less frequency and usually cannot be exploited to execute code of the attacker's choice.<ref name="bugtrag_perl"/>
 
== History ==
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 name="Miller_1990"/>
 
The use of format string bugs as an [[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"/> 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 that brought the issue to common awareness (by providing remote root access via code execution) were published simultaneously on the [[Bugtraq]] list in June 2000 by [[Przemysław Frasunek]]<ref name="Frasunek_2000"/> and a person using the nickname ''tf8''.<ref name="tf8_2000"/> They were shortly followed by an explanation, posted by a person using the nickname ''lamagra''.<ref name="Lamagra_2000" /> "Format bugs" was posted to the [[Bugtraq]] list by Pascal Bouchareine in July 2000.<ref name="Bouch_2000"/> The seminal paper "Format String Attacks"<ref name="Newsham_2000"/> 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"/>
 
== Prevention in compilers ==
Many compilers can statically check format strings and produce warnings for dangerous or suspect formats. In [[GNU Compiler Collection|the GNU Compiler Collection]], the relevant compiler flags are, <code>-Wall</code>,<code>-Wformat</code>, <code>-Wno-format-extra-args</code>, <code>-Wformat-security</code>, <code>-Wformat-nonliteral</code>, and <code>-Wformat=2</code>.<ref name="GCC412"/>
 
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 ==
 
Contrary to many other security issues, the root cause of format string vulnerabilities is relatively easy to detect 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.
 
=== Detection in x86-compiled binaries ===
 
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.'<ref name="team_teso"/>
 
==See also==
* [[Cross-application scripting]] exploits a similar kind of programming error
*[[printf]]
* [[Cross-site scripting]]
*[[syslog]]
* <code>[[printf]]</code>
* <code>[[scanf]]</code>
*[[fscanf]]
* [[syslog]]
* [[Improper input validation]]
* [[SQL injection]] is a similar attack that succeeds when input is not filtered
 
==External linksReferences==
{{reflist|refs=
*[http://doc.bughunter.net/format-string/exploit-fs.html Excellent Paper on Exploiting Format String Bugs]
<ref name="CWE134">{{cite web |work=[[Common Weakness Enumeration]] |publisher=[[MITRE]] |title=CWE-134: Uncontrolled Format String |url=http://cwe.mitre.org/data/definitions/134.html |date=2010-12-13 |access-date=2011-03-05}}</ref>
*[http://doc.bughunter.net/format-string/ More Security Papers about Format String vulnerabilities]
<ref name="team_teso">{{Cite web |date=September 1, 2001 |title=Exploiting Format String Vulnerabilities |url=http://julianor.tripod.com/bc/formatstring-1.2.pdf |website=julianor.tripod.com}}</ref>
*[http://marc.theaimsgroup.com/?l=bugtraq&m=96179429114160&w=2 The first format string exploit]
<ref name="Trends">{{cite web |url=http://cwe.mitre.org/documents/vuln-trends/index.html |title=Vulnerability Type Distributions in CVE |date=2007-05-22}}</ref>
*[http://www.rosiello.org/archivio/fmtbugs.pdf Explaining format bugs and how they can be exploited] by [http://www.rosiello.org/ Johnny Mast]
<ref name="bugtrag_perl">[http://seclists.org/bugtraq/2005/Dec/0030.html Bugtraq: Format String Vulnerabilities in Perl Programs]</ref>
*[http://www.securityfocus.com/data/library/format-bug-analysis.pdf Analysis of Format Strings Bugs]
<ref name="Miller_1990">{{cite journal |url=https://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf |title=An Empirical Study of the Reliability of UNIX Utilities |author-first1=Barton P. |author-last1=Miller |author-first2=Lars |author-last2=Fredriksen |author-first3=Bryan |author-last3=So |journal=[[Communications of the ACM]] |volume=33 |number=12 |date=December 1990 |orig-year=1989 |doi=10.1145/96267.96279 |pages=32–44 |s2cid=14313707 |access-date=2021-10-11 |archive-date=2018-02-07 |archive-url=https://web.archive.org/web/20180207130148/https://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf |url-status=dead }}</ref>
<ref name="Tymm_proftpd">[http://seclists.org/bugtraq/1999/Sep/0328.html Bugtraq: Exploit for proftpd 1.2.0pre6]</ref>
<ref name="Frasunek_2000">[https://marc.info/?l=bugtraq&m=96179429114160&w=2 'WUFTPD 2.6.0 remote root exploit' - MARC], June 2000 by [[Przemysław Frasunek]]</ref>
<ref name="tf8_2000">[https://marc.info/?l=bugtraq&m=96171893218000&w=2 'WuFTPD: Providing *remote* root since at least 1994' - MARC] by tf8</ref>
<ref name="Newsham_2000">[http://seclists.org/bugtraq/2000/Sep/0214.html Bugtraq: Format String Attacks][[Tim Newsham]] September 2000</ref>
<ref name="GCC412">[https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html#Warning-Options Warning Options - Using the GNU Compiler Collection (GCC)]</ref>
<ref name="Bouch_2000">[https://seclists.org/bugtraq/2000/Jul/241 Bugtraq: Format Bugs] [https://www.lysator.liu.se/~kjell-e/tekla/linux/security/bugtraq/2000/format-bugs-2000-07.html Format bugs] July 2000 by Pascal Bouchareine</ref>
<ref name="Lamagra_2000">[https://seclists.org/bugtraq/2000/Jun/339 Bugtraq: format bugs, in addition to the wuftpd bug] June 2000, by Lamagra Argamal</ref>
}}
 
==Further reading==
[[Category:Security exploits]]
* {{cite conference |author-first=Crispin |author-last=Cowan |title=FormatGuard: Automatic Protection From printf Format String Vulnerabilities |conference=Proceedings of the 10th USENIX Security Symposium |date=August 2001 |url=http://www.usenix.com/events/sec01/full_papers/cowanbarringer/cowanbarringer.pdf}}
[[Category:C programming language]]
* {{citation |author-first=Crispin |author-last=Cowan |title=Software Security for Open-Source Systems |publisher=[[IEEE Computer Society]] |url=http://www.computer.org/web/computingnow/securityandprivacy |series=IEEE Security & Privacy |date=January–February 2003}}
* {{cite book |author-first=Tobias |author-last=Klein |title=Buffer Overflows und Format-String-Schwachstellen - Funktionsweisen, Exploits und Gegenmaßnahmen |language=de |publisher={{ill|dpunkt.verlag|de}} |edition=1 |date=2004 |isbn=3-89864-192-9}} (vii+663 pages)
* {{cite book |author-first=Robert C. |author-last=Seacord |author-link=Robert C. Seacord |title=Secure Coding in C and C++ |publisher=[[Addison Wesley]] |date=September 2005 |isbn=0-321-33572-4}}
 
==External links==
* [http://codearcana.com/posts/2013/05/02/introduction-to-format-string-exploits.html Introduction to format string exploits] 2013-05-02, by Alex Reece
* scut / team-[[TESO (Austrian hacker group)|TESO]] [http://julianor.tripod.com/bc/formatstring-1.2.pdf <cite>Exploiting Format String Vulnerabilities</cite>] v1.2 2001-09-09
* [http://projects.webappsec.org/Format-String WASC Threat Classification - Format String Attacks]
* [https://www.securecoding.cert.org CERT Secure Coding Standards]
* [http://www.cert.org/secure-coding CERT Secure Coding Initiative]
* [https://web.archive.org/web/20040403234032/http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string Known vulnerabilities] at MITRE's CVE project.
* [https://cansecwest.com/csw08/csw08-holtmann.pdf Secure Programming with GCC and GLibc] {{Webarchive|url=https://web.archive.org/web/20081121103054/https://cansecwest.com/csw08/csw08-holtmann.pdf |date=2008-11-21 }} (2008), by Marcel Holtmann
 
{{DEFAULTSORT:Format String Attack}}
[[de:Formatstring-Angriff]]
[[Category:SecurityComputer security exploits]]