Symantec Releases Alert for Heap Overflow in AV Products 

infectionvectors.com

February 2005

Update2: Two days following the last report, another ISS discovered AV vulnerability was released, this time a flaw similar to F-Secures (ARJ) in the Trend Micro AV product.

Update: The day following this report, F-Secure (via another ISS discovered vulnerability) released details of a buffer overflow that affects their AV products as well. The F-Secure products allow for an unchecked input buffer when handling ARJ archive files vice UPX with SAV. The details of this report can be found here: http://www.f-secure.com/security/fsc-2005-1.shtml . The two flaws are quite similar; anyone wishing to understand how either exploit may work (it is important to note again that neither vulnerability has produced an exploit in the wild as of yet) should read the coverage below. 

Overview

On 8 February 2005, Symantec released details of a heap overflow present in many of its antivirus tools, including the current version of Symantec Anti Virus (SAV 9.1) and its popular gateway products. The vulnerability potentially allows a specially crafted application execute arbitrary code on a machine running SAV. The alert brought a tremendous amount of attention; a vulnerability such as this, if mass released could precipitate an large scale malware outbreak. The reasons are simple enough:  the "arbitrary code" would almost certainly include stopping and removing the SAV scanning service from a victim machine, meaning that virtually any malware could be executed freely on the device.

However, it is important to note that while the vulnerability is real (discovered by ISS and documented at their site as well), there is no exploit code in the wild as of now and they're not the easiest pieces of code to construct. That doesn't mean heap overflows are impossible to write: there are plenty of examples in the wild including the RPC Long Filename exploit allowing Welchia to propagate and the recent Word Perfect Converter vulnerability (MS04-027), which were available very shortly after the bulletins were made public. The exploit is possible because of a flaw in the way UPX-compressed files are handled. More specifically, the piece of SAV that parses UPX files has an unchecked input buffer that would allow an attacker to overwrite heap memory space and execute nearly any command they wished. 

In a nutshell, heap overflows work like this:

Memory is defined (allocated) in the heap to hold variables used by the running process. Most people are familiar with memory that is allocated by a program when it starts up, the amount of RAM that your word processor takes and only relinquishes when it quits. This is static allocation. Memory that is allocated to a sub process (a subset of the program itself, also known as a subroutine) and then relinquished once the subroutine ends is known as the "stack space" or simply "stack," which is familiar to many users. Entries in the stack must also carry a return address, a pointer back to the parent program which is followed once the subroutine ends. Stack overflows are also fairly common exploits, and are generally considered easier to build than heap overflows. The heap is memory allocated for dynamic variables. 

The traditional depiction of memory space:

Overruns in either case involve passing a string to an input buffer that is too long for the allocated memory. This is possible in cases where the programmer has not placed an input check or control on the amount of data that can be written legally to the buffer. The string overwrites the portion of the memory that holds the intended return address with a new one, an address that points back to itself. It is in this location where the attacker places his/her own code, some malicious action that opens a command shell, executes a companion program, destroys another process, etc. Since the heap allocation itself is not fixed, it is more difficult to construct an exploit that will be capable of consistent success; it is far from impossible, as noted above.

In the specific case of the SAV vulnerability, the flaw exists in the DEC2EXE application, which identifies UPX compressed executables. If an exploit becomes public, its practical application will most likely be to first terminate the SAV real time scanning, possibly then delete the scan engine (to prevent it from being restarted automatically, as it is programmed to do), and execute additional malicious code. This additional code could conceivably be any virus, repackaged and re-released. For details on packaging viruses, see the infectionvectors.com report "Securing Virus Code."

Additional Reading

Details on the Heap Overflow can be found in the following studies:

"w00w00 on Heap Overflows" Matt Conover and w00w00 Security Team, 1999. 

http://www.w00w00.org/files/articles/heaptut.txt 

"Buffer Overflow" Prabhaker Mateti, 2004. 

http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/BufferOverflow/