Solving the Malicious Content Problem

The flaw is in AIM's URI handler for its "aim:" protocol. Exploitation enables remote system compromise by supplying an overly long "goaway" message parameter. To actually attack a vulnerable system, something must trigger URL protocol handling by Windows (e.g., user click) at which time HKEY_CLASSES_ROOT\aim is consulted to determine the shell command to execute for handling of the URL. It is in AIM's parsing of the URL parameter that the overflow occurs.

Such vulnerabilities are not unusual from a technical standpoint. Content parsing flaws involve the way that content is handled or parsed, rather than flaws in the way that request processing occurs or flaws in the way that restrictions on executable script and compiled code are enforced. In the case of URI protocol handler vulnerabilities, the malicious content is essentially a parameter passed to a subroutine, much as any function call receives and handles parameters passed on the stack during runtime execution of compiled code.

A URL That Includes a Parameter is Just Like RPC

Distinguishing between data (or content) and code makes sense only in the absence of vulnerabilities. There is little difference, technically, between invoking a URL that contains a name/value pair parameter and allowing a remote procedure call to occur from the original source of the URL (some unknown location on the network, wherever and whenever the URL was authored) to the URI protocol handler parameter parsing subroutine on the local box. It can be tricky for an attacker to craft precisely the right malicious URL and parameter value to gain control of the instruction pointer and redirect it to arbitrary malicious code, because of limits imposed on the allowable character set for a URL string (support for unicode in URL parameters increases the opportunity for attacks of this nature) such as the fact that null values cannot be passed because they terminate strings.

Analysis of the AIM URI handler goaway parameter vulnerability reportedly reveals that despite being compiled with Microsoft Visual Studio .NET 2003 using the /GS compiler flag to incorporate stack protection through the canary technique described previously (http://www.ddj.com/documents/s=9207/ddj040223sec/), it is nonetheless possible to gain control of the Structured Exception Handler (SEH) pointer and bypass stack-based canary validation of the stack frame's return address. By triggering an exception after replacing the authentic SEH pointer, an attacker is able to force indirect control of EIP by triggering exception handling rather than wait for the current stack frame to return and thereby grant control of EIP to the attacker.

Since parsing of content poses a severe security threat, we must consider the proper and complete solution to the problem. Clearly it is pointless to rely on an antivirus vendor to assemble a list of known bad URLs that can be detected as individual virii that each receive their own name and are considered just more examples of clever compact malware. A malware signature approach to preprocessing every bit of data that is ever parsed by a box would add serious overhead to every process, and signatures would still be perpetually out-of-date. Protocol anomaly detection doesn't work for this particular issue, either, unless we impose a length limit on URLs and just decide to suffer the compatibility hit. Content scanning firewalls/proxies that whitelist known good URLs and impose length limits for all others could offload processing of this class of malicious data, but such approaches still leave huge gaping holes like anything that arrives via SSL and thus cannot be preprocessed by the firewall. Premangling e-mail messages based on security threats detected in URLs that they present to your Mail User Agent is about as bad an idea as any.

Graphic Images Can Attack, Too

If the problem were just with URLs perhaps we could arrive at some viable solution that specifically addresses this threat; removing support for all risky protocol handlers, for example. There's no reason we need to invoke code so easily through the use of RPC syntax such as a URL that includes name/value pairs. A human who knows what aim:// means can decode this class of URI and at the same time evaluate its trustworthiness, choosing whether or not to pass the parameter or whether to filter/remove it when making contact with the specified network resource. But the malicious content problem goes far beyond such limited threat scenarios. Several vulnerabilities have been reported in code that parses image and sound data contained in media file formats.

A severe vulnerability was reported August 4th in the open-source Portable Network Graphics (PNG) library (LIBPNG), which is hosted by Source Forge at the following URL:

http://libpng.sourceforge.net

The original security advisory was released by Chris Evans and can be found here:

http://scary.beasts.org/security/CESA-2004-001.txt

Vulnerability 1 from this advisory describes a "remotely exploitable stack-based buffer overrun in png_handle_tRNS" and offers a proof-of-concept bad PNG. Subsequent to release of this advisory and a patch to the source of LIBPNG by its maintainers, an exploit program designed to create malicious PNG files and attach shell code was also released the following week to bugtraq. See:

http://www.securityfocus.com/archive/1/371454

At this moment, nearly every unpatched build of the LIBPNG source code is likely to be vulnerable to attack merely by presenting the code with the right PNG image. This includes virtually every build of Mozilla for Windows. Ironically, many people just switched to Mozilla when CERT recommended moving away from IE for security reasons.

HTML formatted e-mail messages sent to vulnerable Mail User Agents are likely to result in another wave of worms that self-propagate thanks to automatic PNG image display features in most MUAs that support HTML e-mail. Attacks against individual computer users and companies that rely on vulnerable MUAs are, at present, trivial.

Permanent Solution to the Malicious Content Problem

The only solution to the problem of malicious content, short of a complete redesign of the general-purpose microprocessor and motherboard architecture so that code and data are never permitted to reside on the same physical storage or occupy the same RAM, is to research and resolve each security vulnerability present in the code loaded onto our boxes. Less code is the first priority, better code is the second priority, vulnerability scanning and threat tracking are the third and fourth priorities, and ensuring our capability to guard quickly against any new vulnerability that arises, even without installing a vendor patch, is the fifth priority.

Due to the difficulty of juggling these five simultaneous priorities, all of which are necessary in order to defend against malicious content by resolving or defending against the specific vulnerabilities that allow content to be malicious, my employer, PivX Labs, has adopted the position that every Windows box needs ongoing care and attention by a security expert who performs vulnerability identification and takes action in defense of the box.

This is possible with the help of software that deploys individual vulnerability defenses created to resolve technical design flaws, mitigate specific threats caused by known vulnerabilities, disable (in a reversible way, at runtime) vulnerable or risky features that are not critical to the function of Windows software, and facilitate widespread managed deployment of such defenses soon after they are developed and tested.

For more information on this process and how you can participate or benefit from it, visit http://www.pivx.com/.

Jason Coombs is Director of Forensic Services for PivX Solutions Inc. (NASDAQ OTCBB: PIVX), a provider of security solutions, computer forensics, and expert witness services. Reach him at [email protected].