Outside The Sandbox, But Not Terribly Critical
Adobe today issued an update for Adobe Reader X (new version is 10.1.3), which, among other issues, fixes the outside-the-sandbox msiexec.exe EXE planting vulnerability (CVE-2012-0776) I roughly demonstrated during my RSA Conference US talk last month titled "Advanced (Persistent) Binary Planting."
This article explains the vulnerability and how it could have been exploited. It builds upon our research already published here, which I recommend you read before proceeding if you haven't already.
The Bug
It is a typical EXE planting: Under certain conditions, Reader (specifically, the AcroRd32.exe process) launches msiexec.exe using the CreateProcess function without providing a full path to the executable. This triggers a search for msiexec.exe through the CreateProcess search path as explained here; consequently, if the current working directory of AcroRd32.exe happens to point to a location under attacker's control and said attacker planted a malicious msiexec.exe there, that msiexec.exe would get executed instead of the intended one.
Furthermore, attackers would appreciate the malicious msiexec.exe getting executed outside the Reader's sandbox, i.e. with unlimited permissions of the user running it.
So how does one get the Reader to point its current working directory to a location of a malicious executable? The easiest way is to place a PDF document and msiexec.exe in the same folder and either double-click the PDF or have the PDF opened by some application. Since the double-clicking scenario has been discussed extensively in the past and it is believed to be frustratingly difficult to get a security expert to double-click an unknown document in an Internet-based shared folder, we shall investigate the other vector: application-based document opening.
The Exploit - Stage One
As already mentioned in "Downloads Folder: A Binary Planting Minefield," the Downloads folder - a folder where most leading web browsers store user's downloads - can be a highly suitable location for what could aptly be called side-by-side payload. While most browsers will require user confirmation when a web site tries to download an executable to user's computer, Google Chrome was, and still is, willing to do so without any question - and such process of downloading can be highly unnoticeable. Let's see how this could look like for a user under attack.
The above video demonstrates how a web site can silently get msiexec.exe downloaded to user's Downloads folder by having the user click on a link - in this case, the link took the user to Google search page, but it could as well take him anywhere else, or nowhere, for that matter. A keen observer may have noticed that, around the 19th second of the video, a small Chrome pop-up window appears in the bottom right corner: this is where the download actually occurs in order to prevent the main Chrome window from displaying the button of the downloaded file. Some extra work could make this pop-up entirely invisible.
Now that we have a malicious msiexec.exe in our Downloads folder - possibly sitting there for weeks or months -, it's time for stage 2.
The Exploit - Stage Two
The second stage of the exploit requires a malicious web page to get some PDF document to the Downloads folder (where msiexec.exe is already waiting) and have the browser open it. This sounds easy - but there's a trick: the browser must open the PDF externally, in a separate Reader process, and not in browser's integrated PDF viewer. There is a way to achieve this in Chrome (and other browsers too). In the following video, we use Gmail to deliver an e-mail with a PDF document attached to the targeted user, and use Gmail's download functionality to actually download the PDF to the Downloads folder instead of rendering it directly in Chrome. Let's see what happens.
The video demonstrates one way to get a PDF downloaded (instead of rendered) to user's Downloads folder. Any malicious web site could do the same and not even offer a way for users to see the PDF directly in the browser (which Gmail does offer, by the way).
Also, the video shows what the user has to do in Reader to get the malicious msiexec.exe executed: he has to manually select Help -> Repair Adobe Reader Installation and confirm in by clicking Yes. Hardly what users go about doing on their own all the time, or even occasionally. The attack, therefore, requires social engineering; I'll leave it to others to continue the "How much social engineering is too much?" debate and shall merely point out a possibility that training users to avoid opening e-mail attachments from unknown sources or downloading executables from the Internet may not do much to prevent the same users from trying to repair their Reader in order to reach some strongly desired content.
Administrators Only
An important mitigating factor limits the exploitability of this issue: The Repair Adobe Reader Installation menu item is only available to administrative users. Therefore, if you're logged in to your desktop as a non-admin user, you now know of one more way in which your computer didn't get owned. On the other hand, if you're logged in to Windows 7 as a "protected administrator," you will have this menu item and if you chose to repair the Reader installation, you would probably not hesitate too much when the malicious msiexec.exe asked you to elevate its privileges.
Conclusion
All in all, this was not a terribly critical vulnerability as its exploit scenario includes non-trivial social engineering and it only applies to users working as administrators, but it serves as a nice reminder that EXE planting issues may continue to expose an application - and its users - even after the more commonly understood DLL planting bugs have been eradicated or mitigated. Meanwhile, attackers are probably happy to know that, with Chrome, it is much easier to silently plant an EXE to the Downloads folder than it is to do the same with a DLL.
Take care,
@mkolsek
@acrossecurity
