Hi, this is Will Dormann of the CERT Vulnerability Analysis team. One of the responsibilities of a vulnerability analyst is to investigate the attack vectors for potential vulnerabilities. If there isn't an attack vector, then a bug is just a bug, right? In this post, I will describe a few interesting cases that I've been involved with.
Attack vector analysis is an important part of vulnerability analysis. For example, reading an email message with Microsoft Outlook can be used as an attack vector for the Microsoft Jet Engine stack buffer overflow (VU#936529). With the Microsoft Windows animated cursor stack buffer overflow (VU#191609), reading an email message with Microsoft Outlook Express in plain text mode can also be used as an attack vector. With both cases, it's the analysis of the different attack vectors, not the underlying vulnerabilities, that improve our understanding of the severity. Below are some recent examples where attack vector analysis took an important role.
Microsoft Security Bulletin MS13-023
In MS13-023, Microsoft outlines a vulnerability in their Visio Viewer 2010 software. In the Affected Software table, Microsoft lists both the Visio Viewer 2010 software, as well as the Office 2010 Filter Pack. Microsoft indicated that theMaximum Security Impact of the Filter Pack was None and included a caveat: [1] Severity ratings do not apply to this update for the specified software because the known attack vectors for the vulnerability are blocked.
Attack vector analysis shows that this conclusion is incorrect. First, it's important to know what the Office Filter pack does. The Office 2010 Filter Pack installs a set of iFilter file parsers. According to the Microsoft iFilter documentation,full-text search engines like Indexing Service call the methods of this interface to extract text and property information for creating an index.
What this means is that simply placing a malformed Visio file in a location indexed by Windows Search is all that's required to trigger the vulnerability. Aside from Windows Search, iFilters are used by other products, including Microsoft Internet Information Server (IIS), SharePoint Portal Server, Exchange Server, and SQL Server. All of these constitute viable attack vectors. After discussing this with Microsoft, they have acknowledged the oversight and will be updating the MS13-023 bulletin. More details are available in CERT Vulnerability Note VU#851777.
Fun with Windows XP
I found the vulnerability fixed in MS13-023 by directly fuzzing the Office 2010 iFilters in 2012. But sometimes we find bugs without explicitly looking for them. Just trying to use the software is often enough. What if I offered you two different bugs that that appear to be exploitable on fully-patched Windows XP systems? How valuable are those bugs? Or more specifically, are the bugs even considered vulnerabilities? It's impossible to make that determination without investigating the attack vectors.
Bug #1
I found this bug while using a laggy RDP connection to a virtual machine. Sometimes when you are typing, keys get stuck and will end up repeating. To reproduce this bug, simply type this in a Windows
cmd.exe prompt:dir /odddddd
When you do that,
cmd.exe will just disappear. If you have a debugger attached, you will notice that the exception is an access violation on the instruction pointer. It's not immediately obvious whether an attacker has control of the instruction pointer, but Microsoft's !exploitable rightfully categorizes the crash as EXPLOITABLE.
Bug #2
I found this bug while cleaning my keyboard. To reproduce this bug, simply type around 900 or more characters in a Windows
cmd.exe prompt and then press the TAB key. Just like with the case above, cmd.exe will disappear. Further investigation with a debugger shows that the bug is a stack buffer overflow that overwrites the Structured Exception Handler (SEH). Microsoft !exploitable also rightfully categorizes the crash as EXPLOITABLE.
Now, how severe are these bugs? When considering the impact of a vulnerability, or even whether a bug is a vulnerability at all, we must consider the attack vector. In the two cases above, what would successful exploitation get an attacker that he didn't already have? To trigger the bugs, an attacker would need the ability to provide arbitrary input to a Windows command prompt. In other words, as a prerequisite for triggering either bug, an attacker would already require the ability to run arbitrary commands. And the outcome of successful exploitation would be the ability to run arbitrary code. The difference between these two scenarios is negligible, so they are therefore not even considered a vulnerability!
Conclusion
When looking at software bugs and vulnerabilities, it's important to consider the attack vectors. If you're not looking at attack vectors, you're not seeing the big picture.
No comments:
Post a Comment