Uncontrolled format string: Difference between revisions

Revision as of 22:37, 13 October 2019

Latest revision as of 06:22, 30 April 2025

(15 intermediate revisions by 14 users not shown)

Line 1:

{{Short description|Type of software vulnerability}}

{{Use dmy dates|date=August 2019|cs1-dates=y}}

'''Uncontrolled format string''' is a type of [[code injection]] [[software vulnerability|vulnerability]] discovered around 1989 that can be used in [[security exploit]]s.<ref name="CWE134"/> Originally thought harmless, format string exploits can be used to [[Crash (computing)|crash]] a program or to execute harmful code. The problem stems from the use of [[unchecked 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 <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 the number of bytes formatted to an address stored on the stack.

==Details==

Line 16 ⟶ 17:

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 [[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"/> 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 ==

Line 23 ⟶ 24:

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 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==

Line 39 ⟶ 44:

{{reflist|refs=

<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>

<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>

<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>

<ref name="bugtrag_perl">[http://seclists.org/bugtraq/2005/Dec/0030.html Bugtraq: Format String Vulnerabilities in Perl Programs]</ref>

<ref name="Miller_1990">{{cite journal |url=ftphttps://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">[httphttps://marc.theaimsgroup.cominfo/?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">[httphttps://marc.theaimsgroup.cominfo/?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==

* {{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}}

* {{citecitation |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}}

Line 63 ⟶ 70:

* [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}}

[[Category:Computer security exploits]]