Attack Dangers Posed by ‘Innocent’ Files

Recently there has been a rash of “zero-day attacks” that can be transmitted by a data file and executed by opening the file. These attacks leave users and servers alike at great risk. Simply downloading or uploading a data file that has a successful attack in it and viewing it can turn your computer into a zombie, a computer that unbeknownst to its owner is being used for sending spam, attacking websites, etc. Imagine if even 1 percent of 1 percent of the more than 10 million images on http://images.google.com were infected. The ramifications of such an attack would be enormous.

Several of the most recent and severe zero-day attacks (i.e., attacks that have been discovered but for which no reasonable patch or fix exists) have been on Microsoft Word. While there have been many of these attacks recently, and I will leave the details to those who have already described them so well, all of the attacks have followed a similar pattern. Namely, an attacker could carefully craft a Word .doc file (and in one case an .rtf file) that, when opened in Word or the much less powerful and typically considered safer Word Viewer, would execute arbitrary code that the attacker embedded in the file. That is, by opening such a file, arbitrary code by the attacker will run on your computer with all of your privileges. This code could be a virus that infects other .doc files, damages your computer, steals vital information from your computer, installs spyware, etc.

These vulnerabilities stand out from many others in that they are transmitted in .doc and .rtf files, which are not typically considered executable files, and therefore are not typically given the same degree of human or computerized scrutiny. And while there has been a recent rash of vulnerabilities in Word, the problem spans other operating systems and other data file types including .pdf files on Windows, .gif files in Java, .tiff files on Mac OS X, and many more. A user (or a site developer) would be careful downloading (or uploading) and opening an .exe, .dll or .vba file from an unknown or untrusted source.

But why would anyone be hesitant of a data file? Perhaps an even worse vulnerability is the recently patched .gif vulnerability that can open your computer to attack just by visiting a page that has an embedded GIF file if your browser is written in Java. Similarly, if your server allows the uploading of images (e.g., photos, custom logos, etc.), then it too is at risk. This implies that an application must always take care when uploading a data file from a user.  

Protecting a server against such attacks is extremely difficult. One major complication in protecting against such attacks is that there is a never-ending stream of them being discovered. Hence, even with upgraded antivirus software, your server can still be at risk for an attack. Another complication is that successful exploitation of such a vulnerability can occur without your knowledge. For example, imagine your server uploading an infected .gif file and displaying it on a webpage. The .gif might display correctly, or at least without an error or other event that an administrator would notice, despite having successfully attacked your computer and executed its malicious payload.

Besides the obvious protection of antivirus software, other countermeasures can be deployed, but they all come with a reduction in flexibility or an increase in development time. One countermeasure is to run your application and server with minimal permissions. While this does not protect your server from being attacked, it can help or even prevent your machine from being taken over. The idea behind this is that if the attacker manages to get past your countermeasures and execute arbitrary code, the code will be restricted by the minimal permissions of the application server and hence cannot do great damage. The cost of this countermeasure is that your server is restricted in functionality by its minimal permission set.

Simplifying the format of the data files you will download and process also helps reduce the risk of this type of attack. This is because all of the vulnerabilities come from bugs in the file processing code for the various data formats. The simpler the data file format, the less likely there is to be a bug in the implementation. That being said, it might be unacceptable to your users if your site uploads images but accepts only one or two file formats. In the end, you will have to make trade-offs between business and security requirements.

As an alternative or adjunct to simplifying the file format, extra care can be given to ensure that the code that implements the processing of data files that are uploaded is especially secure. Whether the file processing code is purchased or written in-house, you can insist on various quality standards being met (e.g., Common Criteria). While these standards do not guarantee secure code, they do help.

You can also request that your vendors (or yourself if you are writing the code) employ an analysis tool that analyzes the source code, looking for and reporting bugs that might potentially lead to vulnerabilities. In particular, most data file vulnerabilities that allow remote code execution are caused by buffer overflow bugs, and this is a class of vulnerabilities that source code analyzers are especially good at identifying.

Source code analyzers come with some significant overhead. Even forgetting about the cost of purchasing, installing, learning, incorporating into your software development process, and maintaining the analysis tool, there is the cost of keeping up with the tool’s output. The tools tend to produce false positives—that is, they report potential bugs or vulnerabilities that turn out not to be problems. Depending on your source code and the tool you are using, this can introduce a large overhead.

As a final point, it should be noted that a site does not actually have to attempt to open or host an infected file to be a “carrier” of the problem. For example, Google Images has links to images stored on various sites around the Internet. Any one of those image files might have embedded within it malicious code attempting to leverage one of these data file vulnerabilities. While the site itself (Google in this example) is typically safe from such an external link, the sites’ users are not.

Data files cannot be treated as “safe” just because they contain only data. There is a constant stream of attacks being discovered in the software that processes data-only files that allows executable code to be transmitted. While total protection is difficult without eliminating file uploading, efforts can be made to reduce the potential of such vulnerabilities by reducing the types of data files that are supported, simplifying the types of supported data files, and paying extra attention to the correctness and secureness of code that processes data files that come from potentially untrusted sources.

Neil Smithline, in his role as BEA Security Architect, routinely works with enterprise companies helping them address the multitude of security issues that they confront. His major areas of interest include secure coding practices, development methodologies to improve security, U.S. and overseas security regulations, vulnerability prevention, identification, and correction, as well as many other application security related issues.

References:

• Microsoft  .doc and .rtf vulnerability advisories:

https://www.microsoft.com/technet/security/advisory/929433.mspx

https://www.microsoft.com/technet/security/advisory/933052.mspx

https://www.microsoft.com/technet/security/advisory/919637.mspx

https://www.microsoft.com/technet/security/advisory/925059.mspx

https://www.microsoft.com/technet/security/advisory/932553.mspx

https://www.microsoft.com/technet/security/advisory/932114.mspx

• Sun Java .gif vulnerability advisories:

https://www.sunsolve.sun.com/search/document.do?assetkey=1-26-102760-1

• .pdf advisory for some versions of Microsoft Windows:

https://www.kb.cert.org/vuls/id/511577

• .tiff advisory for some versions of Mac OS X:

https://www.kb.cert.org/vuls/id/988356

• A brief sampling of source code analysis tools—far from an extensive list:

http://www.fortify.com

http://www.ouncelabs.com