Practice
Poison NUL Byte was originally documented as such by Olaf Kirch in a post to the fa.linux.security newsgroup. By embedding NULL bytes/characters into applications that do not properly handle postfix NULL terminators, an attacker can exploit the system using techniques such as local file inclusion .
The Poison Null Byte exploit takes advantage of strings of known length that may contain null bytes, regardless of whether the targeted API uses null-terminated strings. By placing a NULL byte in a string at a specific byte position, the string is terminated at that point, nullifying the remainder of the string, for example a file extension.
Relatively high
Moderate
There are several ways to use the Poison Null Byte exploit, including the following:
rain.forest.puppy in Phrack issue 55 discussed the use of NUL Byte Injection in Perl and how it could be exploited. The results were very similar in PHP.
Below is an example of a PHP script vulnerable to a null byte:
$ file = $ _GET [ 'file' ] ; require_once ( "/ var / www / $ file .php" ) ;
Although the script above is protected by forcing the «.php» file extension, it can be exploited as follows:
The NULL byte injection above will strip off the mandatory appended file extension (.php) and load the /etc/passwd file.
Exploiting a buffer overflow vulnerability in the ActiveX component shipped with Acrobat/Acrobat Reader from Adobe Systems Inc. allows remote attackers to execute arbitrary code.
The issue specifically arises when receiving a link of the following form:
Where [long string] is a long string crafted by the malware, containing valid URI characters. The request must be sent to a web server that truncates the request at the null byte (%00); otherwise an invalid filename is specified and a «file not found» page is returned. Examples of web servers that truncate the requested URI include Microsoft IIS and Netscape Enterprise. Although the requested URI is truncated for the purpose of locating the file, the long string is still passed to the Adobe ActiveX component responsible for rendering the page. This, in turn, triggers a buffer overflow in RTLHeapFree(), allowing an attacker to overwrite an arbitrary word in memory. The responsible instructions from RTLHeapFree() are shown here:
0x44F83AE5 MOV EAX , [ EDI + 8 ]
0x44F83AE8 MOV ECX , [ EDI + C ]
...
0x44F83AED MOV [ ECX ] , EAX
The EDI register contains a pointer to the user-supplied string. Thus, the attacker controls the ECX and EAX registers used in the MOV instruction shown.
Successful exploitation allows remote attackers to use the arbitrary word overwrite to redirect the flow of control and ultimately gain control over the vulnerable system. Code execution will occur in the context of the user who opened the vulnerable version of Adobe Acrobat.
The attacker does not need to create a malicious website, since exploitation can occur simply by appending malicious content to the end of any embedded link and pointing it to any Microsoft IIS or Netscape Enterprise web server. Clicking a direct malicious link is also not required, since it can be embedded in an IMAGE tag, an IFRAME, or an auto-loading script.
Successful exploitation requires the payload to be crafted so that certain input regions are acceptable within a URI. This includes the initial injected instructions as well as some of the overwritten addresses. This increases the complexity of successful exploitation. While not trivial, exploitation is certainly plausible.
In late 2007, Arshan Dabirsiaghi carried out limited research describing null byte injection in Java. Arshan discovered two methods where Java improperly handles a NULL byte.
The following code was highlighted on Arshan's website as vulnerable:
String path_to_file = request. getParameter ( "target" ) + ".xls" ; File f = new File ( path_to_file ) ; delivery_to_user ( contentsOf ( f ) ) ;
In similar PHP/C/C++ code, one could quickly exploit the infamous null byte kernel behavior to view any arbitrary file on the system. But this also works in Java, because File(file_path) passes user input to open(1) or its Windows equivalent, which is written in C.
See Arshan's reference example for more information.
Several .NET namespaces contain a number of .NET functions that are vulnerable to Poison Null Byte attacks. When the .NET CLR does not properly handle user-supplied null bytes, successful injections can occur.
Null bytes are treated as data in the .NET CLR, so null bytes do not terminate .NET strings. However, strings are terminated at the first null byte found in calls to functions that are native POSIX-compliant. Compatibility-related issues arise when data containing a null byte is used to directly call a native C function through .NET.
A remote attack can be crafted that arbitrarily terminates a parameter used in the vulnerable method(s) by terminating native function calls through null byte injection.
There are a number of known .NET functions that are vulnerable to null byte injection:
Server.MapPath will terminate any returned string when a Null byte is injected in the filename parameter, thereby nullifying any data appended to the user input.
Below is an example of Server.MapPath null byte injection used by Paul Craig in his .NET null byte injection assessment :
Sub Page_Load ( ) dim name as string dim RealName as string name = request ( "name" ) & ".uploaded" RealName = MapPath ( "" ) & "\" & name response . write ( "Mappath value of name variable:" & MapPath ( name ) & " " ) response ."Real value:" & realname & " " ) End Sub
If a null byte is appended to the name variable (name = c:\boot.ini%00), the string is terminated before the .uploaded concatenation.
There are several ways to prevent Poison Null Byte injections in PHP. These include escaping the NULL byte with a backslash; however, the most recommended way to do this is to strip the byte out entirely using code like the following:
$ file = str_replace ( chr ( 0 ) , '' , $ string ) ;
As in PHP, Perl has several options for dealing with NUL injections. Also as in PHP, it is recommended not to escape the byte but to strip it out entirely, using code like the following:
$ data = ~ s / \ 0 // g ;
Update Adobe to the latest version. Or change the Adobe Acrobat/Acrobat Reader settings so that PDF files do not open automatically when accessed through a web browser. When prompted, save the file to disk first before opening it, thereby closing off the exploitation vector described.
This can be done using the following steps:
The .NET issues were fixed by the following patches:
KB928365 (Security Update for Microsoft .NET Framework 2.0)
KB928366 (Security Update for Microsoft .NET Framework 1.1)
Note that these do not fix null byte issues in every case.
Comments