Confirmed: Adobe 'PDF Flaw' Actually XP Bug, Says Microsoft
11:20 am ET October 13, 2007 - Late Friday, Microsoft Director of Security Response Mark Miller confirmed to BetaNews that the vulnerability identified in the company's latest security bulletin is identical to the one discovered by security researcher Petko D. Petkov, and originally attributed to Adobe PDF.
3:10 pm ET October 11, 2007 - Adobe spokesperson John Cristofano confirmed to BetaNews this afternoon that the subject of yesterday's Microsoft security bulletin was indeed the same vulnerability affecting Adobe PDF files in Windows XP. This revelation, coupled with the technical details of the problem described by Microsoft's own security team late yesterday, means that the flaw previously attributed to Adobe software is actually being caused by Microsoft Windows XP in tandem with Internet Explorer 7.
What for several weeks was being reported by BetaNews and others as a flaw in Adobe Acrobat's and Adobe Reader's handling of protocols embedded in URLs bears more than a striking similarity to a critical vulnerability in Windows XP and Internet Explorer 7 reported in an advisory from Microsoft's security team late yesterday.
Microsoft is admitting it has discovered a new vector for intentionally malformed URIs to potentially trigger a malicious action. Though the advisory itself is vague as to what that action might be, a post on Microsoft's security blog yesterday revealed far more details.
The Microsoft team reports having discovered that a type of malformed URI that Internet Explorer 6 would typically reject when received by another application running in Windows XP, was being processed by Internet Explorer 7.
As it turned out, the team explained, when IE7 was updated to work with Windows Vista, the pairing of the new browser with the new operating system resulted in malformed URIs being rejected, but in a new way. As a result, testers may have missed the lack of rejection that took place when IE7 was paired with XP.
Microsoft's tests involved the mailto: resource identifier, which is incidentally the same one that triggered the arbitrary execution of code in tests of PDF files by GNUCitizen.org researcher Petko D. Petkov.
| This video by GNUCitizen.org researcher Petko D. Petkov demonstrates the effects of an intentionally crafted URI embedded in a PDF file. Simply launching the PDF file from Windows Explorer can trigger an executable. In this case, to be safe, Petkov launched Calculator and Notepad. |
But as the Microsoft team explained, it doesn't have to be mailto: that triggers the problem: "This is not a vulnerability in any specific protocol handler, even though the mailto: protocol handler is used in our example," reads yesterday's blog post. "The examples we have seen involved the mailto: protocol handler being asked to handle URIs containing a % (percent sign). An example of this would be test%../../../../windows/system32/calc.exe".cmd, which is clearly not a valid email address. When a user clicks a link to a URI, the application showing that link to users decides how it is supposed to be handled."
From there, the post goes on, in the case of "safe" protocols such as mailto: and http:, applications could trust the API function ShellExecute() to handle the URI. For IE6, that API function was trusted to filter out unwanted elements such as that pesky percentile, and perhaps even drop suspicious URIs altogether rather than risk running their contents through that function.
While ShellExecute() was originally created to run executable files by name as though they'd been launched from the file manager (the shell), later it could launch documents the same way (e.g., double-clicking on an .XPS spreadsheet file brought up Excel), and eventually URIs could launch Web pages in IE.
But because the API function is a one-stop shop, strings that look like URIs to an application may get processed like local files to the operating system, as though they were being launched from "the shell" by the user and not by an application. To borrow a Microsoft phrase, "This behavior is by design."
So applications designers ended up trusting the relationship between Microsoft's operating system and its own browser to handle any deficiency with URIs. That relationship between IE6 and XP was fraught with problems initially, but multiple patches have resolved a number of mangled identifier issues. When the relationship between IE7 and Vista became different -- apparently shifting the filtering function away from the API and back toward the kernel -- that appears to have opened up a hole between IE7 and XP that wasn't there before.
Interestingly, Microsoft's security team is now suggesting that applications vendors (evidently including Adobe) should rely less upon Windows to do the filtering of URIs on their behalf.
"Our plan is to revise our URI handling code within ShellExecute() to be more strict," the team wrote yesterday. "While our update will help protect all applications from malformed URIs, application vendors who handle URIs can also do stricter validation themselves to prevent malicious URIs from being passed to ShellExecute(). We have seen several vendors introduce additional validation as a way to protect their customers from this issue."
One of those vendors may be Adobe, which yesterday received global attention in the general press for having produced for several years what reporters called a flawed product. As it turns out, that negative attention may end up being undeserved.
BetaNews has contacted representatives from Adobe and Microsoft for further comment on this issue, including whether the PDF flaw and the XP/IE7 flaw are identical.