Security Vulnerability Research & Defense

IE 8 XSS Filter Architecture / Implementation

Recently we announced the Internet Explorer 8 XSS Filter and talked a bit about its design philosophy. This post will describe the filter’s architecture and implementation in more detail.

Design Goals

The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.” Our baseline approach needs to satisfy the following three conditions:

• The XSS Filter must be compatible.
  • There should be minimal, ideally zero, disruption to benign content/data. We might be able to achieve effective filtering if we were to drop all non-alphanumeric characters from input, however this would be an unrealistic and overbearing solution. Any solution that involves directly modifying request URLs is likely to persist corrupted data on the server-side. Similarly, approaches that would ask the user questions they can’t answer or block entire pages are not acceptable.
• The XSS Filter must be secure.
  • In general it must not be possible to subvert the filter by modifying attacks that are otherwise intentionally blocked. Although the XSS Filter cannot mitigate all possible XSS attacks, it can win some critical battles decisively. We can push as far as possible to maximize the XSS Filter’s effectiveness as long as we are also careful not to compromise compatibility or performance.
• The XSS Filter must be performant.
  • Users prefer a fast browser to a slow one, even if the slower one is “more secure.” So some approaches are simply not acceptable for performance reasons. For example, creating an extra instance of the browser rendering engine for each navigation would be too impactful to consider.

In implementing the filter, we made decisions to best meet the above goals.

Practical Considerations

The XSS Filter must be in a position to observe and intercept requests and responses from the browser to the web server. In Internet Explorer, this is possible via a MIME Filter. The prototype implementation of the XSS Filter was in fact implemented as a MIME Filter, but for performance it was moved into MSHTML (the browser rendering engine) when we built Internet Explorer 8.

Architecture / Implementation

 
Figure A: XSS Filter Hosted in Internet Explorer 8

 
Figure B: XSS Filter Logic Flow

Figures A and B depict a high level view of the XSS Filter. Let’s dig into the details.

For performance, the XSS Filter only takes effect for navigations within the browser which can result in the execution of script. There’s no need for the XSS Filter to operate on resources such as images (as long as they are truly images when rendered by Internet Explorer).

The filter also checks the source and destination URLs of navigations within the browser. If the navigation is cross-site, or the source cannot be determined (ex: the user clicked on a Favorite) then the navigation is filtered.

The XSS Filter can be enabled/disabled per-zone. For the Beta 2 release the XSS Filter will be enabled for the Internet and Restricted Sites zones, but not the Local Intranet zone. Administrators can choose to enable or disable the XSS Filter for any zone via group policy.

The core XSS Filter engine operates in two stages:

1. HTTP GET / POST data is scanned to match a set of heuristics that identify XSS attack vectors. Matches are used to build signatures to identify markup/script as replayed in the HTTP response.

2. Generated signatures are used to scan the HTTP response. Markup/script which has been identified by a signature is neutered to block execution.

Validating that an XSS attack has actually been replayed into the response maximizes XSS detection reliability – “reflected XSS” requires reflection. Having the capability to identify and neuter the replayed markup/script allows the filter to avoid overbearing mitigations such as querying the user, modifying outgoing requests, or blocking entire pages.

Our approach is performant in that the only notable “heavy lifting” is the scan of the HTTP response body, which will only occur in cases where signatures are generated. Signature generation is highly indicative of an actual XSS attack and it is rare during everyday browsing.

Fun with Regular Expressions – Part 1: Heuristics

If a navigation has met the criteria for filtering, the filter takes the URL as well as any POST data associated with the request, decodes it as necessary, and uses regular expressions to identify XSS attack vectors. These case-insensitive patterns are the filtering heuristics. Here is an example:

{<sc{r}ipt.*src[whitespace or forward-slash]*=}

This heuristic will identify SCRIPT tags with SRC attributes. While SCRIPT tags may be common in HTML, their presence in a URL or POST data is one indication of an XSS attack.

In the example heuristic above, note that the character within the inner braces is what we will refer to here as the neuter character. Each heuristic can have one or more neuter characters. Each neuter character, in this case ‘r’, indicates a character that will eventually be modified by the filter in the HTTP response body in order to block the XSS attack. The ‘#’ character is used as the neuter replacement character – it is effective in breaking HTML elements as well as script blocks into which it is injected.

The selection of neuter characters in any heuristic is very important. The wrong neuter characters chosen for a heuristic can subvert the filter. As an example, picking a quote symbol as a neuter character would cause the filter to neuter quotes. A smart attacker could use this behavior to force a match and neuter a quote on a page, intending to enable an XSS attack that wouldn’t otherwise be possible.

A match on a heuristic does not in and of itself trigger the filter to detect XSS. Rather, it indicates to the filter that the HTTP response body must be examined to validate that the script in the input URL or POST data was in fact replayed to the output page.

The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.

Fun with Regular Expressions – Part 2: Signatures

As heuristics are matched, the filter generates one signature for each match. A signature is a new regular expression that will be used to scan the HTTP response body for the replayed suspect input. The neuter replacement character is temporarily put into place in the input after a signature is matched. Matching then continues for a heuristic until no more matches can be found in the input. Signatures are generated for URLs without neuter replacement characters in place. Otherwise the signatures would themselves contain neuter replacement characters and they would not correctly match attacks present in the HTTP response.

With each heuristic, a list of safe characters is provided. For the heuristic that detects script tags, the safe characters are the greater-than and less-than characters and also alpha-numerics. The safe characters effectively form the essence of the XSS attack the filter is attempting to identify.

Why signatures?

If the filter were to simply search for a match verbatim it would not necessarily find one. The web server may incidentally remove or translate particular characters from the request as it is replayed. It is in fact common and attackers can use this behavior to their advantage.

Safe characters are restricted to the “low-ASCII” range (0x00 – 0x7F) so that we can essentially remain character-set agnostic. Character sets that are capable of alternate “low-ASCII” encodings (eg: UTF-7) are not currently special-cased, however some new restrictions are being placed on the general usage of these character sets moving forward. (These changes are outside the scope of this blog post but stay tuned to my blog for more details).

Here is an example match for the heuristic that detects script tags:

<SCRIPT src=”http://www.fabrikam.com/evil.js”

The signature generated for this match would be:

<SC{R}IPT¤src¤¤http¤¤¤www¤fabrikam¤com¤evil¤js¤

Each ¤ in the signature indicates a non-safe character from the original match. A sequence of zero to N unspecified characters will match any ¤. (Currently N is 10)

If no signatures have been generated for a particular page then the filter permits the page to load without modification – no XSS was detected.

However, if signatures do exist, the filter scans the HTTP response body for each signature. Once identified, the filter records exactly which character(s) must be neutered, as indicated in the signature by the characters within the braces. Once the signature list is fully processed the neuter replacement characters are put into place and the HTTP response body is passed on to render in the browser.

The page will render normally except the information bar will notify the user that the page was modified and the XSS attack will be disabled.

XSS Filter Limitations

Like all security mitigation and protection technologies, the XSS Filter’s approach does have limitations, being that it is a pragmatic balance between application compatibility, security, and performance. Some examples:

• Injection into some contexts is not blocked. Ex: Scenarios where content can be injected directly into javascript without breaking out of a string.

• Injections facilitated by some HTTP headers are not currently blocked. Ex: “Referer” based injection.

• If a page contains multiple nearby injection points, attacks can be constructed that thwart the XSS Filter.

These are all issues that undoubtedly occur on real web sites. The XSS Filter design philosophy dictates that we make a distinction between issues that generally enable the XSS Filter to be bypassed vs. issues that apply only in certain situations. The issues above, while very notable, clearly fall into the latter category. As time goes on we will continue to enhance the XSS Filter to maximize its effectiveness, however we will not compromise web site compatibility in the process.

Conclusion

It is challenging to mitigate XSS in a way that balances the needs of compatibility, security, and performance. The XSS Filter’s two-stage approach helps us achieve these goals by very specifically targeting reflected (“Type-1”) XSS attacks. This architecture allows us to mitigate the XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

- David Ross, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

August 19, 2008, 4:15pm: Updated with correct date

MS08-049 : When kind of authentication is needed?

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.

MS08-050 : Locking an ActiveX control to specific applications.

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

- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-043 : How to prevent this information disclosure vulnerability

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!

• Make a backup copy of the XLSX file that you will be editing.
• On a Windows XP or Windows Vista machine change the file extension of the affected .XLSX file to .ZIP
• Using the Windows shell (i.e. Windows Explorer) open the ZIP file by double clicking on it and then double click on the 'XL' folder inside.
• In the 'XL' folder click on 'connections.xml' and drag it out of the ZIP file to a local folder or your desktop.
• Right-click on the 'connections.xml' file and select 'Open With' and then choose 'Notepad'
• Locate the string "connection=" and then search for "PWD=" later in that string. Remove any characters after the "PWD=" and before the ";" characters as these are the improperly saved password for the connection. For example if you have an XLSX file with a saved connection password you might see a string like the following in connections.xmls:

<?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>

• Save the connections.xml
• Drag the connections.xml file back into the ZIP folder making sure to place it in the 'XL' folder inside the ZIP file.
    a. NOTE: Some applications such as Winzip will default to placing the file at the root of the ZIP archive and will not overwrite the file in the 'xl' folder by default.
• Change the file extension of the ZIP file back to XLSX and then open the document in Excel 2007, click on the 'Data' menu and then click 'refresh all' in the connections part of the ribbon and verify that you are prompted for the password.

- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-042 : Understanding and detecting a specific Word vulnerability

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 file
Wait – 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 editors
While 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 stream
Once 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 stream
If 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.

- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-041 : The Microsoft Access Snapshot Viewer ActiveX control

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.*

How to parse the .doc file format

This past February, Microsoft publicly released the Office binary file formats specification.  These describe how to parse Word, Excel, and PowerPoint files to review or extract the content.  Because they describe the structure of these file formats in detail, we think the file format specification will be particularly interesting to ISVs who write detection logic for malware scanners (such as Anti-Virus software).  Let us start delving into these documents by examining the basics of parsing a Word Document created with this legacy binary file format.  This discussion will not cover the new OOXML format introduced in Word 2007.
 
Compound Binary Format
First things first, in order to parse these older formats you will need to have knowledge of the Compound Binary File Format.  The specification for this format is available online.  Upon examination, you can see that the format is like a file system, similar to FAT.  There are directories called storages, which contain data files named streams.  All of this data is potentially fragmented across the file in various sectors described by the internal FAT.  There are libraries available to parse this format so you don’t have to re-invent the wheel if you don’t want to.  Use the Windows COM API, starting with the StgOpenStorageEx function, or one of the several freely available parsers and viewers to extract the individual data streams.  Compound binary files are actually quite common, and the COM API is a good way to access the data stored in these files.

High Level Structure of Word Data
In valid Word documents, there exists a stream named WordDocument.  Go ahead and view this stream’s contents.  It begins with a structure named the File Information Block, or FIB, which is described on page 141 of the Word Binary File Format specification.  This massive structure both contains data and acts like a guide map for the rest of the document.  At offset 0x9A in the FIB you will find a placeholder value named Rgfclcb.  This marks the beginning of the offset/length pairs which describe structure locations for the rest of the document.  These are offsets into another stream, named 0Table or 1Table.  To find out which of these two streams is being referenced, examine the 16 bit value at FIB offset 0xA and look at bit number 10 (AND it with 0x200).  If that bit is 0, then the offsets are referring to the 0Table stream.  If it’s 1, then the 1Table stream.

This xTable stream contains much of the formatting data that Word uses to construct the document on your screen.  Each offset points at a different structure, so check the Word Binary File specification for additional details about the data stored at a particular Table stream location.

A Real Example
Now, let’s combine this information with some details about a patched vulnerability to see how we can detect a possible exploit attempt.  MS06-060 fixed a vulnerability in the Print Merge State (PMS) structure, which is stored in one of the xTable streams. 

First, use the method described above to determine if this document is using the 0Table or 1Table stream.

Next we have to find out if there is a PMS structure in the document, and if so, what its offset is in the xTable stream.  There are two possible places in the FIB that might store the location of this structure, fcPms and fcPmsNew.  First check fcPms.  The corresponding length value for that offset value is called lcbPms, and it’s a DWORD located at FIB offset 0x1FE.  If that value is non-zero, then the fcPms DWORD at FIB offset 0x1FA contains the xTable offset we need.  If the length value is 0, then we need to check the second possible location, fcPmsNew at FIB offset 0x48A.  The length value for this one is called lcbPmsNew, and is at FIB offset 0x48E.  If this DWORD is 0, then the document contains no PMS structures.  If it is non-zero, then the DWORD fcPmsNew contains the offset in the xTable stream of the PMS structure.

Finally, if the document does contain a PMS structure, examine it in the table stream you identified earlier at the offset you just read from the FIB.  The structure looks like:

struct PrintMergeState {
   WORD Reserved1;
   BYTE One;
   BYTE Two;
   DWORD Reserved2;
   BYTE Three;
   BYTE Reserved3[7];
   BYTE Four;
};

Within this structure there are four bytes of interest named One, Two, Three, and Four within the definition above.  Verify that the values of One and Two are set to either 0 or 1.  For Three and Four, verify that those values are within the range 0 to 5 inclusive.  Any other values for these fields are invalid and the document should be flagged as potentially abusing the MS06-060 vulnerability. 

In the following example, the WordDocument stream started at file offset 0x1C00, and the 1Table stream started at file offset 0xC00.  After finding lcbPms (at 0x1C00 + 0x1FE) to be non-zero, we look at the PMS structure at 0xC00 + 0x1A6, and see that the value named “Three” is > 5, so this document might be trying to exploit MS06-060.

We hope that you’ve found this a helpful example of how you can use the Word Binary File Format specification to accurately describe and detect attempts to exploit specific security vulnerabilities.

MS08-040: How to spot MTF files crossing network boundary

Today we released MS08-040 to patch several vulnerabilities in the SQL Server Database Engine; one of them involves the SQL Server backup file format.  The format is also known as MTF (Microsoft Tape Format).  The vulnerability requires an attacker to be able to force the SQL Server to load a malicious MTF file from the local drive or from the network.

Under normal circumstances (and by default), only authenticated SQL Server users can load an MTF file.  In order to remotely exploit this vulnerability, the attacker could leverage a separate SQL injection vulnerability and then trigger the SQL Server to load a malicious MTF file from the Internet; the SQL Server will then try to access the file using the Server Message Block (SMB) protocol or WebDAV. Web-based Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.)  Consequently, you will see SQL Server make an outbound connection to the Internet on ports 80, 443, 139, or 445.  In most cases, the Database Engine (sqlservr.exe) should not talk to the Internet on these ports so you should block them both inbound and outbound at the firewall  unless they are needed by other components.  Therefore, if you see SQL Server loading MTF files from the Internet, it is probably bad news.  You can fingerprint an MTF file on the network by looking at its header which is a 94-byte structure defined as follows:

typedef struct {
0x00:  UINT32 dblktype;
...
0x56:  UINT16 svid; 
...
0x5D:  UINT8 mver; 
} MTFHDR;

dblktype” should always be 0x45504154 (“TAPE”).  The “svid” field indicates the vendor and it should be 0x1200 (Microsoft).  An example header with the two fields highlighted is shown below.

You should always set up your SQL server with best security practices as outlined in http://technet.microsoft.com/en-us/library/ms144228.aspx and http://www.microsoft.com/technet/prodtechnol/sql/2005/sql2005secbestpract.mspx

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-039: Which users are vulnerable to the OWA XSS vulnerability?

Today we released MS08-039 which addressed several XSS vulnerabilities in Microsoft Exchange’s Outlook Web Access component.  While this is an update to be applied to the Exchange server, the clients who use OWA are the computers potentially at risk.  We’d like to explain a little more about the vulnerability so that you can determine whether you or your organization are at risk.

OWA has two modes: OWA Light (or OWA Basic for Exchange 2003), and OWA Premium. In short, if OWA Light/Basic is used, you are vulnerable to the XSS vulnerability. You can tell whether OWA Light is used via the “Use Outlook Web Access Light” check box in OWA’s logon screen.

So which mode is the default mode in OWA?

To use OWA Premium, the browser must include support for ActiveX and the restricted IFRAME features.  Therefore, if you use a browser without these features, you will only be able to use OWA Light.  The OWA login screen displays the mode to be used.  In the screenshot below, a browser that does not support ActiveX and/or the restricted IFRAME features can only use OWA Light – you can see that there is no option to un-check the “Use Outlook Web Access Light” box.

If you are using Internet Explorer and have enabled ActiveX, OWA will default to Premium mode.  In the default case, in fact, Internet Explorer users will be forced to use Premium mode.  However, an Exchange administrator could choose to configure their Exchange servers to enable OWA Light for all  users or could even force OWA Light for all users.  However, Exchange cannot be configured to force all clients to OWA Premium mode.  OWA Premium users are not vulnerable to the XSS vulnerabilities addressed with this security update. 

Here’s the login screen when a browser supports the features required of Premium Mode and the Exchange administrator has been configured to enable OWA light:

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-037 : More entropy for the DNS resolver

We released security bulletin MS08-020 two months ago to improve the DNS transaction ID entropy.  You can read more about the MS08-020 algorithm change in this blog entry.  Increasing the entropy makes it more difficult for attackers to spoof DNS replies.  Today, we released MS08-037 to further increase the difficulty of spoofing DNS transactions.  We modified the DNS client and server resolvers to send requests from a random source port.  Previously, an attacker would need to only guess the correct transaction ID.  After applying MS08-037, an attacker will need to guess both the transaction ID and source port in order to successfully spoof a DNS reply.  In short, randomized source ports for DNS transactions adds another unique piece of information to DNS transactions, which makes spoofing more difficult.

The default size of the randomized socket pool on Win2k3 and down-level platforms is 2500 ports which is configurable by modifying the registry value:

HKLM\System\CurrentControlSet\Services\DNS\Parameters\SocketPoolSize

Another notable registry value is

HKLM\CurrentControlset\services\tcpip\parameters\MaxUserPort

Refer to http://technet2.microsoft.com/windowsserver/en/library/730fb465-d402-4853-bacc-16ba78e9fcc01033.mspx?mfr=true for more information on MaxUserPort.  On Win2k3, MaxUserPort is defined as the maximum port up to which ports may be allocated for wildcard binds.  Basically, MaxUserPort, if set, defines the dynamic port range.  It should also be noted that the MaxUserPort value has a different meaning in Vista and Win2k3.  In Win2k3, MaxUserPort, if set, defines the dynamic port range (it starts from 1024 to MaxUserPort).  In Vista, MaxUserPort, if set, signifies the number of dynamic ports, so the range is from StartRange (whatever has been configured, default is 49k) to StartRange+MaxUserPort.  Refer to: http://support.microsoft.com/kb/929851. 

To summarize, the fixed behavior on Win2k3 and down-level platforms after installing the patch are:

-          If MaxUserPort is set, then allocate ports randomly from 1024-MaxUserPort
-          If MaxUserPort is not set, then the ports will be allocated randomly from the 49152-65535 range.

The default port pool was chosen to pull random ports within a range consistent with BSD heritage where many systems have safely allocated ports dynamically from that range.  Doing so outside of that range has a small chance of introducing network failure, but in most cases won’t cause problems.  If you would like to add more entropy, you can grow the port limit by modifying the MaxUserPort and related registry keys.

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

The IE8 XSS Filter

Hello, our team and IE have recently collaborated on a new IE8 feature that was announced today – the XSS Filter.  Check it out here: http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx

This effort demonstrates our commitment to helping our product teams benefit from the knowledge we have gained while defending our products from attack.  Stay tuned to our blog for more stories like this in weeks to come... 

 - Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

New tools to block and eradicate SQL injection

The MSRC released an advisory today that discusses the recent SQL injection attacks and announces three new tools to help identify and block these types of vulnerabilities. The advisory discusses the new tools, the purpose of each, and the way each complements the others. The goal of this blog post is to help you identify the best tool to use depending on your role (i.e. Web Developers vs. IT administrators).

Web Developers Recommendations

• The Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool that identifies SQL Injection vulnerabilities in ASP code (ASP pages are the ones that have been under attack). In order to run MSCASI you will need source code access and MSCASI will output areas vulnerable to SQL injection (i.e. the root cause and vulnerable path is identified). In our view, fixing the root cause of the bug is the best way to eradicate vulnerabilities. MSCASI scans ASP source code and generates warnings for first order and second order SQL Injection vulnerabilities. Please refer to the SQL team’s blog and KB 954476 for more details.

IT/Database Administrators Recommendations (as well as Web developers)

We are recommending two of the new tools announced today. One can help identify SQL injection vulnerabilities by crawling the website.  The other one aims to block potential SQL injection attacks by filtering malicious requests.  The website crawler will be useful if you don't have access to the source code.  

• Microsoft worked with the HP Web Security Research group to release the Scrawlr tool. The tool will crawl a website, simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr uses some of the same technology found in HP WebInspect but has been built to focus only on SQL Injection vulnerabilities. This will allow an IT/DB admin to easily find vulnerabilities similar to the ones that have been used to compromise sites in recent attacks. No source code is required to run this tool. From a starting URL, the tool recursively crawls that URL in order to build up a site tree that will be then analyzed for SQL injection vulnerabilities. For more information check out the HP Web Security Research blog. 

• In order to block and mitigate SQL injection attacks (while the root cause is being fixed), you can also deploy SQL filters using a new release of URLScan 3.0. This tool restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from being executed on the server. It uses a set of keywords to block certain requests.  If a bad request is detected, the filter will drop the request and it will not be processed by SQL. That said, if a SQL injection flaw has been identified, we highly encourage you to fix the root cause of the problem instead of attempting to produce the perfect filter (since in our view this is error prone). Please refer to one of the two IIS blog posts (1, 2) and the technical documentation for more details.

The following table summarizes the pros and cons of these tools.

Tool	Usage	Pros	Cons	Users
MSCASI	Identifies SQL Injection vulnerabilities in ASP code through static source code analysis.	Identify the root cause of the bug at the source code level.	This version currently only works on ASP pages.	Web developers
Scrawlr	Detect SQL vulnerability using runtime analysis by crawling a website.	No source code is required.	Cannot identify the line of code responsible.	IT/DB Administrator,Web developers
UrlScan v3.0 Beta	Runtime filtering that blocks the types of HTTP requests that Internet Information Services (IIS) will process.	URLScan filter can be easily deployed to mitigate SQL injection attack while the root cause is being fixed.	Not fixing the root cause, thus the risk has not been eliminated completely.	IT Administrators

MS08-036: PGM? What is PGM?

This morning we released MS08-036 to fix two denial-of-service vulnerabilities in the Windows implementation of the Pragmatic General Multicast (PGM) protocol (RFC 3208).  You probably have never heard of PGM.  Only one engineer on our team had ever heard of it and he previously worked as a tester on the core network components team.  PGM is a multicast transport protocol that guarantees reliable delivery from multiple sources to multiple receivers. It is a layer 4 transport protocol, peer to TCP and UDP.  You can send/receive data with PGM by creating a socket with SOCK_RDM type and IPPROTO_RM protocol.  For example:

s = socket(AF_INET, SOCK_RDM, IPPROTO_RM);

For more information on how to program with PGM, check out the MSDN reference.

The PGM protocol is available on all versions of Windows since XP.  However it is disabled by default on all versions.  We expect that most networks out there will not have a great deal of PGM traffic on it.  Therefore, if you can detect PGM protocol usage on your network and discover a sudden flood of PGM traffic, it’s likely your network is being attacked.  You can detect PGM on the wire by checking the “Protocol” field in the IP header.  PGM’s protocol ID is 113 (0x71).  Both Netmon 3.1 and Wireshark contain PGM parsers.  Here is an example PGM packet capture in Netmon:

P.S. If we’re wrong about the extent of PGM use and there are common applications that use it, please let us know and we’ll revise this blog entry.

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-033: So what breaks when you ACL quartz.dll?

In some of the multimedia MSRC bulletins that have been released there is a workaround listed about changing ACL’s on Quartz.dll. So, what exactly breaks when we ACL Quartz.dll?

Quartz.dll is a core component of the DirectShow framework. Originally a component of DirectX, DirectShow eventually took on a life of its own as multimedia recording and playback evolved. The DirectShow framework outlines a plug-in model for processing and managing an end to end content pipeline.   Many applications have taken advantage of this pipeline. Some examples include Windows Media Player, Windows Media Encoder, Windows Movie-Maker, Window Media Center, as well as many third party multimedia applications such as video camera applications.

Therefore, after ACLing quartz.dll, applications that count on DirectShow functionality will not work properly. This could include, but is not limited to tasks such as audio/video capture and playback of multiple media types.  For example, in Windows XP,  DirectShow is used for playback of all file types in Windows Media Player.  When Quartz.dll is ACLed, everything breaks: no file can be played back by Windows Media Player.  

Things turn a little bit more complex in Windows Vista. Starting with Windows Vista, the playback experience has been redesigned to take advantage of new OS features. As such, ACL'ing quartz.dll will have the same overall impact as previously mentioned on apps that rely on DirectShow.   However, some apps such as Windows Media Player that can also take advantage of these new OS features may still have some scenarios where content playback will work.

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-030: All bark and no bite? The case of the Bluetooth update

This morning we released a critical update for Windows addressing a vulnerability in the Microsoft Bluetooth stack (MS08-030). The bulletin is rated Critical since it allows an attacker to corrupt memory in the Windows kernel, which theoretically could allow an attacker to execute code in the context of the operating system on the remote computer. While we cannot conclusively disprove that attackers will be able to reliably exploit this issue, we still feel it is worth noting the factors which in our opinion make this issue less severe than the bulletin may imply.

First, since the issue is triggered over a Bluetooth link, the attacker would have to be within fairly close physical proximity to the target system. (The standard range of Bluetooth is in the order of meters, although an attacker could use specialized antennas to increase this). This is in contrast to most other remote flaws affecting TCP/IP and related protocols which can be exploited over large distances (e.g. the Internet).

Second, as the security bulletin states, the issue is triggered by a flood of SDP messages. To exploit the issue, an attacker must attempt to trigger a small timing window on the target host. The chances of this succeeding are dependent on the speed of the target, the rate at which SDP packets can be sent from the attacker and received by the target, and the number of processors on the target system. Based on our investigation, a single-processor machine is unlikely to be affected by this issue.

Finally, the attacker needs to find a way to control the memory layout of the target system, and place data they control in the correct location, all within the timing window mentioned above. This is different from other bugs that easily allow an attacker to control the memory layout (think of heap-spraying).

The information above is presented to help customers understand that the “sky is not falling” in terms of immediate risk due to this vulnerability. That said, we still recommend customers patch any affected systems, especially those that have Bluetooth enabled.

- Security Vulnerability Research & Defense Bloggers

*Postings are provided "AS IS" with no warranties, and confers no rights.*