This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Format String"

From OWASP
Jump to: navigation, search
 
 
(19 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v2}}
+
{{Template:OWASP Testing Guide v4}}
  
Go back to [[Testing_for_buffer_overflow]]
 
  
==Introduction==
+
== Summary ==
  
Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc.  
+
This section describes how to test for format string attacks that can be used to 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 functions that perform formatting, such as printf().
  
Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc.
 
  
The vulnerability arises on account of format functions being called with inadequate parameters and user controlled Data.  
+
Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc. Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc. The vulnerability arises when format functions are called with inadequate parameters validation and user controlled data.  
  
A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such %s, %n, %x to the application by means of command line argument argv[1].
 
  
This situation tends to become precarious on account of the fact that a user who can supply format specifiers can perform the following malicious actions:
+
A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such as %s, %n, %x to the application by means of command line argument argv[1].
 +
 
 +
 
 +
This situation tends to become precarious since a user who can supply format specifiers can perform the following malicious actions:
 +
 
 +
'''Enumerate Process Stack:''' This allows an adversary to view stack organization of the vulnerable process by supplying format strings, such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.
  
'''Enumerate process Stack:''' This allows an adversary to view stack organization of the vulnerable process by supplying format strings such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.
 
  
 
'''Control Execution Flow:''' This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.
 
'''Control Execution Flow:''' This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.
  
'''Denial of Service:''' In case the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.
 
  
==Black Box==
+
'''Denial of Service:''' If the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.
  
 +
 +
==How to Test==
 +
=== Black Box testing ===
 
The key to testing format string vulnerabilities is supplying format type specifiers in application input.
 
The key to testing format string vulnerabilities is supplying format type specifiers in application input.
 +
  
 
For example, consider an application that processes the URL string  
 
For example, consider an application that processes the URL string  
http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.
+
http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If a format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.
 +
 
 +
 
 +
Format string vulnerabilities manifest mainly in web servers, application servers, or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases, an error reporting or logging function like syslog( ) has been called insecurely.
  
Format string vulnerabilities manifest mainly in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog( ) has been called insecurely.
 
  
 
When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like
 
When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like
  
'''http://hostname/cgi-bin/query.cgi?name=john&code=45765 '''  
+
'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john&code=45765 </nowiki>'''  
  
 
can be altered to  
 
can be altered to  
  
'''http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x'''
+
'''<nowiki>http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x</nowiki>'''
  
In case a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.   
+
If a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.   
 
   
 
   
In case of unavailability of code, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.  
+
 
 +
If code is unavailable, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.  
 +
 
  
 
Take the instance of code (1) :
 
Take the instance of code (1) :
Line 52: Line 60:
 
}
 
}
 
</pre>
 
</pre>
 +
  
 
when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.
 
when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.
 
  
 
[[image:IDA Pro.gif]]  
 
[[image:IDA Pro.gif]]  
  
  
On the other hand when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.
+
On the other hand, when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.
  
 
[[image:IDA Pro 2.gif]]
 
[[image:IDA Pro 2.gif]]
+
 
==White Box==
+
 
 +
=== Gray Box testing ===  
  
 
While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.
 
While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.
Line 74: Line 83:
  
 
<pre>
 
<pre>
Printf
+
printf
Fprintf
+
fprintf
Sprintf
+
sprintf
Snprintf
+
snprintf
Vfprintf
+
vfprintf
Vprintf
+
vprintf
Vsprintf
+
vsprintf
Vsnprintf
+
vsnprintf
 
</pre>
 
</pre>
  
There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood. 
 
  
==References==
+
There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood.
* Team Teso, Exploiting format String Vulnerabilities
 
http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html
 
* Analysis of format string bugs
 
http://julianor.tripod.com/format-bug-analysis.pdf
 
* Format functions manual page
 
http://www.die.net/doc/linux/man/man3/fprintf.3.html
 
  
==Whitepapers==
 
* A paper on format string attacks by Tim Newsham
 
http://comsec.theclerk.com/CISSP/FormatString.pdf
 
  
 
==Tools==
 
==Tools==
* ITS4, A static code analysis tool for identifying format string vulnerabilities using source code
+
* ITS4: "A static code analysis tool for identifying format string vulnerabilities using source code" - http://www.cigital.com/its4
http://www.cigital.com/its4/
+
* An exploit string builder for format bugs - http://seclists.org/lists/pen-test/2001/Aug/0014.html
* A disassembler for analyzing format bugs in assembly
 
http://www.datarescue.com/idabase/
 
* An exploit string builder for format bugs
 
http://seclists.org/lists/pen-test/2001/Aug/0014.html
 
  
 
+
==References==
{{Category:OWASP Testing Project AoC}}
+
'''Whitepapers'''<br>
[[OWASP Testing Guide v2 Table of Contents]]
+
* Format functions manual page - http://www.die.net/doc/linux/man/man3/fprintf.3.html
 +
* Tim Newsham: "A paper on format string attacks" - http://comsec.theclerk.com/CISSP/FormatString.pdf
 +
* Team Teso: "Exploiting Format String Vulnerabilities" - http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html
 +
* Analysis of format string bugs - http://julianor.tripod.com/format-bug-analysis.pdf

Latest revision as of 16:39, 31 July 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Summary

This section describes how to test for format string attacks that can be used to 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 functions that perform formatting, such as printf().


Various C-Style languages provision formatting of output by means of functions like printf( ), fprintf( ) etc. Formatting is governed by a parameter to these functions termed as format type specifier, typically %s, %c etc. The vulnerability arises when format functions are called with inadequate parameters validation and user controlled data.


A simple example would be printf(argv[1]). In this case the type specifier has not been explicitly declared, allowing a user to pass characters such as %s, %n, %x to the application by means of command line argument argv[1].


This situation tends to become precarious since a user who can supply format specifiers can perform the following malicious actions:

Enumerate Process Stack: This allows an adversary to view stack organization of the vulnerable process by supplying format strings, such as %x or %p, which can lead to leakage of sensitive information. It can also be used to extract canary values when the application is protected with a stack protection mechanism. Coupled with a stack overflow, this information can be used to bypass the stack protector.


Control Execution Flow: This vulnerability can also facilitate arbitrary code execution since it allows writing 4 bytes of data to an address supplied by the adversary. The specifier %n comes handy for overwriting various function pointers in memory with address of the malicious payload. When these overwritten function pointers get called, execution passes to the malicious code.


Denial of Service: If the adversary is not in a position to supply malicious code for execution, the vulnerable application can be crashed by supplying a sequence of %x followed by %n.


How to Test

Black Box testing

The key to testing format string vulnerabilities is supplying format type specifiers in application input.


For example, consider an application that processes the URL string http://xyzhost.com/html/en/index.htm or accepts inputs from forms. If a format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.


Format string vulnerabilities manifest mainly in web servers, application servers, or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases, an error reporting or logging function like syslog( ) has been called insecurely.


When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like

http://hostname/cgi-bin/query.cgi?name=john&code=45765  

can be altered to

http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x

If a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.


If code is unavailable, the process of reviewing assembly fragments (also known as reverse engineering binaries) would yield substantial information about format string bugs.


Take the instance of code (1) :

int main(int argc, char **argv)
{
printf("The string entered is\n");
printf(“%s”,argv[1]);
return 0;
}


when the disassembly is examined using IDA Pro, the address of a format type specifier being pushed on the stack is clearly visible before a call to printf is made.

IDA Pro.gif


On the other hand, when the same code is compiled without “%s” as an argument , the variation in assembly is apparent. As seen below, there is no offset being pushed on the stack before calling printf.

IDA Pro 2.gif


Gray Box testing

While performing code reviews, nearly all format string vulnerabilities can be detected by use of static code analysis tools. Subjecting the code shown in (1) to ITS4, which is a static code analysis tool, gives the following output.


ITS4.gif


The functions that are primarily responsible for format string vulnerabilities are ones that treat format specifiers as optional. Therefore when manually reviewing code, emphasis can be given to functions such as:

printf
fprintf
sprintf
snprintf
vfprintf
vprintf
vsprintf
vsnprintf


There can be several formatting functions that are specific to the development platform. These should also be reviewed for absence of format strings once their argument usage has been understood.


Tools

References

Whitepapers