MS08-041 fixes a vulnerability in the Microsoft Access Snapshot Viewer ActiveX control. It’s an interesting vulnerability so we wanted to go into more detail about platforms at reduced risk and also more about the servicing strategy for this vulnerability.
Windows Vista at reduced risk?
We first heard about this vulnerability from customers sending in reports of active attacks. We issued security advisory 955179 in response to those attacks. Attackers had found a race condition that tricked this legitimate ActiveX control into downloading a file from any internet URL and writing it to any path on the local disk. The first attacks placed a trojan malware executable in the user’s startup folder to be run on next reboot. Later, attackers figured out how to overwrite core system files and then immediately cause those files to be loaded. The most recent attacks we have seen will even prompt the potential victim to download the ActiveX control if they do not have it already installed.
There is some good news, however. Windows Vista has a great defense-in-depth protection about these types of attacks. The IE7 “Protected Mode” feature of Windows Vista does not allow ActiveX controls (or anything running inside the browser) to write out to sensitive areas of the file system. So Vista users are at a substantially reduced risk from infection through the normal IE attack vectors that we have seen used in these attacks.
MSRC ActiveX control servicing strategy
There is one wrinkle in our servicing strategy for this vulnerability. You might recall from previous ActiveX control cases that the MSRC typically ships an updated binary along with a killbit for the old binary and phoenix bit pointing to the new binary. The new binary, the killbit, and the phoenix bit will all be installed by a single package ensuring that legitimate use of the ActiveX control will not be disrupted. One or two months later, the MSRC will ship a stand-alone killbit to block any instantiation of the old control. The idea is that any legitimate users of the control by then would have the phoenix bit pointing to the new binary so killing the old clsid entirely will not disrupt legitimate use of the binary.
MS08-041 is the package that ships the updated Snapshot Viewer ActiveX control, the killbit for the old clsids, and the phoenix bit pointing the old clsids to their new clsid equivalents. So if you install MS08-041, you will be safe from attacks leveraging this vulnerability in snapview.ocx. However, keep in mind that if you don’t already have Microsoft Office installed, you likely won’t be offered MS08-041 by Microsoft Update. It makes sense because if you don’t have the control installed, you wouldn’t want Microsoft to push it down onto your computer. From the previous paragraph, recall that the MSRC will follow the initial package with a stand-alone killbit. That will ship with the next ActiveX killbit package after users who legitimately use and need the Snapshot Viewer ActiveX control have installed the new binary. In the meantime, if the computers you control do not have Office installed, you should consider setting the killbit on those computers to be sure you’re safe. You can find the steps to do so in the bulletin workaround section.
- Security Vulnerability Research & Defense Bloggers*Postings are provided "AS IS" with no warranties, and confers no rights.*
A few weeks ago we posted a blog entry titled "How to parse the .doc file format". Today's blog post will show you how to use that information to check whether a .doc file is specially crafted to exploit MS08-042, one of the vulnerabilities addressed by today's security updates. This particular vulnerability is being exploited out in the real world so we believe the benefits of releasing more information about it to help the defenders outweighs the risk of attackers learning more about the already-public vulnerability. So today we are releasing information about this vulnerability and talking about a few tools that will help you analyze documents.
Defragment the .doc fileWait – defragging is just for file systems, right? Well, if you remember our discussion of the compound binary format, it can be described as a file system within a file. One of the properties of the compound binary format is that the streams can be fragmented in the file. Last time we talked about using APIs to extract the streams of interest from the .doc file. This time we’ll talk about how to read the .doc file itself and detect attempts to exploit the vulnerability. Our technique will only work on a file that is not fragmented. You can learn about how fragmentation works in these files by reading the compound binary format specification.
A quick note about hex editorsWhile you can use any hex editor you like to do this analysis, for our examples we’re going to use the 010 Editor v3 from SweetScape Software. We chose this editor for its Binary Template functionality, which is well suited to detecting potential exploits of this vulnerability.
Reading the WordDocument streamOnce you’ve defragmented the .doc file you want to analyze, open up the WordDocument stream, look at the 16 bit value at offset 0xA, and examine bit number 10 (AND it with 0x200). If that bit is 0, then we will be working with the 0Table stream, and the 1Table stream otherwise.
Next, look at the 2 DWORDs that start at WordDocument stream offset 0x42A. The first is an offset into the xTable stream, the second is a length. If the length is 0, then the structure we are interested in does not exist in this file, and so it is not crafted to exploit MS08-042. Otherwise, read on to find out we use the offset to determine if the file is malicious.
To make things easier, I’ll use examples from our 010 binary template for this next section. You can find the entire template attached to this blog entry. In our 010 binary template, after the portion that parses the compound binary format, we loop through the streams looking for one that is named WordDocument. Once we find it, we make note of which xTable stream to use, as well as the offset and length we just discussed:
// Loop through all of the streams looking for the ones we are interested in for( dwCtr = 0; exists( stDir[dwCtr] ); ++dwCtr ) { // Memcmp doesn't compare arbitrary memory, just strings... if( stDir[dwCtr].wCbEleName == 14 && stDir[dwCtr].strEleName[ 0] == 48 // 0 && stDir[dwCtr].strEleName[ 1] == 84 // T && stDir[dwCtr].strEleName[ 2] == 97 // a && stDir[dwCtr].strEleName[ 3] == 98 // b && stDir[dwCtr].strEleName[ 4] == 108 // l && stDir[dwCtr].strEleName[ 5] == 101 // e && stDir[dwCtr].strEleName[ 6] == 0 ) { dwTableStream[0] = dwCtr; dwTableStrLen[0] = stDir[dwCtr].dwSizeLow; if( dwTableStrLen[0] < OleHeader.dwMiniStrMax ) { qwTableStrOffset[0] = MiniSectOffset( stDir[dwTableStream[0]].dwStartSect ); } else { qwTableStrOffset[0] = SectOffset( stDir[dwTableStream[0]].dwStartSect ); } } // Determine which table stream to use FSeek( qwWordStrOffset + 0xA ); WORD Flags; local uint iWhichTableStream = (Flags & 0x200) >> 9; // Get the offset into the Table Stream and structure length from the WordDocument stream FSeek( qwWordStrOffset + 0x42A ); DWORD fcSttbfBkmkFactoid; DWORD lcbSttbfBkmkFactoid; if( lcbSttbfBkmkFactoid == 0 ) { Printf( "Clean document.\n" ); Printf( "This document doesn't contain any smart tags.\n" ); Warning( "Clean document." ); Exit( 0 ); }
And finally, reading the xTable streamIf we’ve gotten this far, we have a properly parsed .doc and we’ve determined that there is a smart tag structure in the xTable stream. Now we need to examine the structure in the table stream, so we’ll define the structure in our binary template. You can see which value we’re testing to detect potential exploits as well:
typedef struct { WORD wWordCount; byte bOtherData[12]; if( wWordCount < 6 ) { Printf( "This document is malicious!\n" ); Warning( "This document is malicious!" ); Exit( 2 ); } } SMARTTAG ; typedef struct { WORD wAlwaysFFFF; WORD wNumSmartTags; WORD wExtraData; } SMARTTAGSECTION ;
Finally, we need to actually read in the SMARTTAGSECTION structure, and then all of the SMARTTAG structures it tells us about:
FSeek( qwTableStrOffset[iWhichTableStream] + fcSttbfBkmkFactoid ); SMARTTAGSECTION stSmartTagSection; for( dwCtr = 0; dwCtr < stSmartTagSection.wNumSmartTags; ++dwCtr ) { SMARTTAG stSmartTag; FSeek( startof( stSmartTag ) + ( stSmartTag.wWordCount + 1 ) * sizeof( WORD ) ); }
Having a smart tag with WordCount < 6 sets up the condition for the vulnerability to occur, but it won’t actually be triggered unless there is some other corruption in the document which causes Word to abort the loading of the document. Since a benign .doc should never have a smart tag with WordCount < 6, we are done with our detection logic! You'll find this logic encapsulated in the attached binary template.
Of course, being able to detect attempts to exploit a vulnerability is no substitute for installing the security update! We strongly encourage you to install MS08-042 as soon as possible.
In this month’s update for Excel we addressed an interesting CVE (CVE-2008-3003) – the first vulnerability to affect the new Open XML file format (but it doesn’t result in code execution). This is an information disclosure vulnerability that can arise when a user makes a data connection from Excel to a remote data source and checks a checkbox to have Excel NOT save the password used in that connection to the file. The checkbox had no affect when saving the file in the new Open XML (.XLSX) file format and the password was thus errantly saved to the file – thus the vulnerability. So in case you haven’t heard – the new Open XML files (the Office files that end with an ‘x’ in the extension i.e. .docx, .xlsx., .pptx) are actually ZIP containers! In fact if you change the file extension to .ZIP you can open the new Office Open XML files in Winzip or the Windows shell to check out the contents for yourself without the need of fancy hex editor. If you do that – what you will see is mostly a bunch of XML files and image files (assuming you have images in your Office apps) inside. As it turns out – to verify / repro this bug report - all that was needed was the Windows shell (to open the renamed Office ‘.zip’ file) and Notepad (to edit one of the XML files inside). In fact the Windows shell and Notepad are all that’s needed to work around this bug (as detailed in the workarounds section of the bulletin for this vulnerability) and remove the accidentally leaked information from your .XLSX files!
Here’s how you can inspect an .XLSX file to see if it has an improperly saved database connection password in it and how you can remove it and fix the file up yourself!
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><CONNECTIONS xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"> <CONNECTION id=1 saveData="1" background="1" refreshedVersion="3" type="1" name="Query from Test Machine"> <DBPR command="SELECT * FROM FOO" connection="DRIVER=SQL Server;SERVER=SQLSERVER;UID=sa;PWD=sa;APP=2007 Microsoft Office system;WSID=CLIENT;DATABASE=master"> </CONNECTION></CONNECTIONS>
MS08-050 concerns an ActiveX control that can be maliciously scripted to leak out personal information such as email addresses.
There appeared to be no need for the control to have this behaviour so giving it a Kill-Bit seemed the correct approach to take. During the extensive testing that each security update undergoes, however, it became apparent that the Kill-Bit wasn’t ideal as it partially broke the Remote Assistance application.
So how do we kill off a control, keep the Remote Assistance functionality and still protect our customers?
Firstly the original control must receive a Kill-Bit to prevent the control being foisted on to users.
Secondly the control was modified so that when it initializes it first checks to see what process it’s running within. If the process attempting to invoke the control is Remote Assistance (1) or if the caller is in a white list of applications found in the registry (2), then the control is permitted to be loaded. Otherwise it will not load.
Finally we issue a Phoenix-Bit (AlternateCLSID) so that Remote Assistance can continue to use the old ClassID.
1 "%SystemRoot%\pchealth\helpctr\binaries\helpctr.exe"2 "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\ImageName\” Where ImageName is the name of the executable that is to be added to the list (e.g. foo.exe), has the value "AllowMessengerExecHandleFailure" of type DWORD and the data set to 1
MS08-049 is an update for the Windows Event System service to correct an authenticated elevation-of-privilege vulnerability. We received a question via email yesterday about the type of authentication needed to exploit CVE-2008-1456. Our security bulletin was a little ambiguous with one reference to "logon credentials" and another to "domain credentials". The email question was from an IT security manager who wondered whether his hardened servers could be compromised remotely. He had disallowed local logon rights to regular users.
The Event System service runs in a shared svchost.exe process with the default svchost COM access permissions. That service ACL grants local or remote access to all Authenticated Users. The Authenticated Users group includes all domain users and all local workstation accounts on the targeted machine. However, the guest account, even if enabled, is not authenticated so COM will block the call, whether made locally or remote. The MSRC has updated the bulletin to be more precise.
We hope this clarifies the risk of this vulnerability. It is only rated "Important" due to its effect of authenticated elevation-of-privilege. However, an authenticated attacker can remotely compromise any unpatched Windows machine in your network that is domain joined, including your domain controller or Exchange server. It's one of those "Importants" that is very important to address, so we highly recommend that you apply this update.
- SVRD Bloggers
*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
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
The past few days, we have had service isolation on our minds here in Redmond after the POC code posting last week from Cesar Cerrudo. Nazim Lala from the IIS team posted a great blog entry about the fix and why it is taking so long to release it. I expect it to be close to the amount of code churn as XP SP2. We’re backporting a huge amount of infrastructure work from the Vista servicing hardening effort back down-level. It’s really a monumental amount of work for a security update. Nazim's blog entry goes into more detail.
But I wanted to make sure everyone knew what set of customers are at risk. I think Cesar outlined it pretty well but just to recap: an attacker would need to be executing code in the context of a Windows service to use this exploit. More precisely, an attacker needs the SeImpersonatePrivilege privilege in their token in order to start the privilege escalation.
IIS is a good attack vector in scenarios where a hosting provider hosts untrusted code. Cesar also points out the SQL Server scenario where a SQL DBA has admin rights to the database but not on the machine running the database. There might be other attack vectors as well. You can investigate any potential attack vectors in your scenario by checking the token in any process running code from untrusted sources. The easiest way to do so is via Process Explorer. Double-click on any running process and click the “Security” tab to see the options. Here are a couple examples.
Svchost running as NETWORK SERVICE:
cmd.exe running as an unprivileged user:
To recap, the vulnerable scenario is as follows:
1 – Process token has SeImpersonatePrivilege privilege2 – Process is running at privilege level less than SYSTEM (otherwise, no escalation)3 – Process runs untrusted code or allows untrusted users to execute code
If your network fits this criteria, we strongly encourage you to review Security Advisory 951306 and apply the workarounds listed.
Microsoft Host Integration Server 2006 is an interesting product. It allows developers to manage business processes on IBM mainframe and AS/400 (big iron) servers as XML web services. You can find a free trial version available for download at http://www.microsoft.com/hiserver/downloads/default.mspx.
Unfortunately, access to the management interface was not properly locked-down. MS08-059 is an update for Microsoft Host Integration Server 2006 which secures the SNA RPC service interface. It is possible for an attacker to run code remotely and take control of a Microsoft Host Integration Server 2006 if this update is not installed. The update adds better RPC user verification as well as locking down some of the unneeded remote management functionality exposed by this interface.
If you use Microsoft’s Host Integration Server 2006 in your environment, it’s important that you secure the servers running HIS as soon as possible. Our first recommendation, of course, is to apply the security update as soon as possible. If you cannot apply the update right away (it does require a reboot), there are a couple things you can do to limit your exposure to any potential attacks abusing this vulnerability.
One temporary workaround is to use the Service Control Manager to disable the SNA RPC service, and prevent it from starting automatically. This will prevent the vulnerable service from running, but will also prevent remote management. Firewalling the RPC port is not a valid workaround, since the port used for communicating is dynamically assigned when the service starts.
One thing you could do to limit risk is to run the service as a lower-privileged user. Any successful attacks would then run at a reduced privilege, hopefully limiting the extent of the damage. We already recommend this during installation by displaying a pop-up warning (see screenshot below). We also mention this in documentation, but some people might have missed that so we’re emphasizing this option in this blog post. Running under a non-administrator account reduces potential risks and will limit exposure of the vulnerable interface.
MS08-061 addresses several vulnerabilities in win32k.sys where you can execute arbitrary code in kernel mode. These bugs can only be exploited locally and there is no remote vector based on our investigation of the vulnerability.
One of these vulnerabilities involves multiple kernel mode accesses of user mode data leading to an interesting race condition. When accessing user mode data, kernel mode code needs to “capture” a copy of the user mode data locally and avoid accessing the user mode original multiple times. Failing to do so results in a type of problem known as a “double fetch”.
When the kernel captures the user mode data, it works with the local copy (located in kernel address space) and is not affected by any changes that happen to the user mode copy. This capture avoids race conditions involving different values of the data being returned from subsequent user mode fetches.
A double fetch from user mode could lead to several security vulnerabilities. In the case of MS08-061, we are addressing an inadequate pool allocation and a later memory pool overflow. Let’s look at a piece of the vulnerable source code:
// Attacker controls lParam void win32k_entry_point(...) { […] // lParam has already passed successfully the ProbeForRead my_struct = (PMY_STRUCT)lParam; if (my_struct ->lpData) { cbCapture = sizeof(MY_STRUCT) + my_struct->cbData; // [1] first fetch […] // my_struct ->lpData has already passed successfully the ProbeForRead […] if ( my_allocation = UserAllocPoolWithQuota(cbCapture, TAG_SMS_CAPTURE)) != NULL) { RtlCopyMemory(my_allocation, my_struct->lpData, my_struct->cbData); // [2] second fetch } } […] }
As you can see in the above vulnerable code, there are two fetches of the same user mode data ([1] and [2]). Since the kernel cannot guarantee that both fetches will have the same value, a small allocation can occur in [1] but later in [2] the kernel copies the data with a bigger length causing a memory pool overflow. This can easily be performed with a parallel, and high priority, thread changing the supplied address range (pointed by lParam) in a loop.
A kernel developer should keep these issues in mind and should capture whatever data the code is using from user mode avoiding double fetches.
// Attacker controls lParam void win32k_entry_point(...) { […] // lParam has already passed successfully the ProbeForRead my_struct = (PMY_STRUCT)lParam; cbData_captured= my_struct->cbData; lpData_captured = my_struct->lpData; if (lpData_captured) { cbCapture = sizeof(MY_STRUCT) + cbData_captured; […] // lpData_captured has already passed successfully the ProbeForRead […] if ( my_allocation = UserAllocPoolWithQuota(cbCapture, TAG_SMS_CAPTURE)) != NULL) { RtlCopyMemory(my_allocation, lpData_captured, cbData_captured); } } […] }
- Fermin J. Serna, SVRD Blogger