One of our blogging goals is to give you a peek “behind the scenes” into our security response process. We thought you might be interested in the story behind MS08-055, this month's OneNote bulletin.
In March, a security researcher sent in a report of an information disclosure vulnerability that affected OneNote 2007, a part of Office 2007. He had come up with a clever way of abusing the onenote:// protocol handler to expose OneNote notebook contents. The Office team built a security update to address the vulnerability and the MSRC started building a security bulletin to address the information disclosure vulnerability. We typically rate Information disclosure vulnerabilities as 'Important' severity. (link to example bug bar)
When we dug into the vulnerability during our 'hacking-for-variations' investigation, we found that OneNote used mso.dll to process parameters passed in via the protocol handler. More investigation turned up a buffer overrun vulnerability in mso.dll that could be triggered by passing arguments to the onenote:// protocol handler. Now the case's severity rating was bumped up from Important to Critical with the effect being changed from Information Disclosure up to Remote Code Execution.
Unfortunately, the vulnerable MSO.dll is used by almost all versions of Office and some developer tools for shared Office functionality. So to address this vulnerability, we are now shipping a security bulletin with aggregate severity of Critical to all computers that have OneNote 2007 installed (external report) and also all computers that have Office 10, 11, or 12 (due to the internal find). In our testing, we have not been able to hit the mso.dll issue through any vector except the onenote:// protocol handler. If you unregister the protocol handler (described in the bulletin), you should be safe from this vulnerability until you are able to apply the security update. But please do apply the security update, even if you are not using OneNote 2007.
- Jonathan Ness, SVRD Blogger
*Postings are provided "AS IS" with no warranties, and confers no rights.*
You may have noticed that the MS08-052 bulletin has a workaround that’s a little different than you’re probably used to seeing in our bulletins. That’s because gdiplus.dll, on all OSes after Windows 2000, is stored in something called the Windows Side By Side Cache (WinSxS).
The purpose of the WinSxS cache is to keep old versions of assemblies around in case an application requires a specific version, and doesn’t want newer versions. It’s implemented as a folder under %windir% called winsxs. In that folder, you’ll find a subfolder for each version of each assembly that’s managed by the WinSxS cache, with a copy of the assembly in each folder. When an application tries to load a DLL that’s managed by the WinSxS cache, Windows checks to see if that application has a manifest specifying which version of the DLL it wants. If that information doesn’t exist, the application gets the default version of that DLL.
You probably have many versions of gdilplus.dll on your system right now. That’s why our workaround included a step to restrict access to all files named gdiplus.dll in %windir%\winsxs
for /F "tokens=*" %G IN ('dir /b /s %windir%\winsxs\gdiplus.dll') DO cacls %G /E /R everyone
That way, no matter what version an application requests, it will be unable to load the DLL, and therefore be isolated from the vulnerable code.
After you install the update, clearly you don’t want any application to be able to load one of the old versions that will still be present in the WinSxS cache. That’s why the update includes a WinSxS policy rule that instructs Windows to ignore requests for versions of gdiplus.dll older than the updated one, and to supply the updated one to those applications instead. This is a feature of the WinSxS cache designed for exactly this sort of situation.
- Kevin Brown, SVRD Blogger