This was originally published on the CSO website and is reprinted with their permission.
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.g
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 created 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
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., 62Common 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 63buffer 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
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
References:
• Microsoft .doc and .rtf vulnerability advisories:
http://www.micr
http://www.micr
http://www.micr
http://www.micr
http://www.micr
http://www.micr
• Sun Java .gif vulnerability advisories:
http://www.suns
• .pdf advisory for some versions of Microsoft Windows:
http://www.kb.c
• .tiff advisory for some versions of Mac OS X:
http://www.kb.c
• A brief sampling of source code analysis tools—far from an extensive list:
http://www.fort
http://www.ounc
Leave a comment