Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi everyone. Jonathan from the SWI team in the MSRC here.
My team researches potential mitigations and workarounds as part of the comprehensive investigations we do for each security bulletin. We regularly discover information that could help customers better understand how to protect themselves via mitigations and workarounds. This month, I wanted to give you information about the Virtual PC and Virtual Server bulletin and some "best practices" guidance to help protect yourself from this class of vulnerability. Also, I wanted to help explain why the Microsoft Office Isolated Converter Environment (MOICE) is not listed as a workaround for MS07-044, the Excel bulletin.
MS07-049 addresses a vulnerability in Virtual PC and Virtual Server. If an attacker can get malicious code running inside the guest operating system, there was potential to "break out" and run code on the host OS. Be sure to patch this one right away if you ever knowingly run bad code (malware) inside the Virtual PC or Virtual Server isolation environments. We stated in the bulletin that malicious code that runs inside a virtual machine can take complete control of the host system and that's true. However, there are different degrees of "complete control." For example, "Virtual Server" is the affected service in the case of a Virtual Server 2005 compromise. This service runs in the security context NetworkService. Anytime malicious code runs on your system, it is bad news, but it is pretty hard to escalate from NetworkService to LocalSystem when you're running with fully-updated Windows Server 2003.
Unlike Virtual Server, Virtual PC runs as whichever user launches Virtual PC. It does work fine when run as a non-admin, so if you're running malicious code inside the virtualization environment, we'd highly encourage you to run the program as a non-admin user to reduce the impact of this class of vulnerability.
Christopher Budd and I have written a bit about the MOICE stand-alone tools in this blog. You might remember that MOICE is a new stand-alone security mitigation technology that opens the document using the Office 2007 validation code and "wrings out" any of the bad stuff it finds. You can read more about MOICE in Microsoft Security Advisory (937696). If you are using Office 2003 in any environment where you open documents from untrusted sources (like Internet e-mail attachments), we highly encourage you to enable MOICE.
As part of our mitigation and workaround investigation to make sure we give customers accurate guidance, we test MOICE against the vulnerability being addressed. We have been pleased with its effectiveness so far. For example, you might have noticed that MOICE protected customers against the vulnerabilities addressed in last month's Excel bulletin (MS07-036). However, this month's Excel bulletin (MS07-044) did not list MOICE as a workaround and I wanted to explain why it does not protect in this particular case.
This vulnerability was in opening XLW workspace files. By design, the MOICE tool supports XLS, XLT, and XLA but not XLW. So in this particular case MOICE doesn't protect against this vulnerability because it’s outside the scope of the tool. That said, if your organization primarily uses the new Office 2007 Open XML file format, you can use the FileBlock key as described in the bulletin to block XLW and all other binary file formats from being opened while you roll out the security update across your organization. As a reminder, we talk about both MOICE and FileBlock in Microsoft Security Advisory 937696 where you can get more information.
We hope that this additional information was helpful to you. Thanks for reading!
*This posting is provided "AS IS" with no warranties, and confers no rights.*