Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

April, 2009

  • AutoRun changes in Windows 7

    As some of our readers are well aware, Conficker and other malware is taking advantage of the AutoRun functionality as a spreading mechanism. Furthermore, over the last couple of months, there has been a significant increase of this threat, as more malware is abusing this functionality. Further information about this specific threat has been highlighted in the recent Security Intelligence Report (look for Win32/AutoRun) and the Microsoft Malware Protection Center (MMPC) blog.

    Background

    Before going into the specifics changes, it is important to understand the difference between AutoRun and AutoPlay:

    • AutoRun is a technology used to start some programs automatically when a CD or another media is inserted into a computer. The main purpose of AutoRun is to provide a software response to hardware actions that a user starts on a computer.
    • AutoPlay is a Windows feature that lets a user select which program starts when a specific type of media, such as music CDs, or DVDs containing photos, is inserted. During AutoPlay, the Autorun.inf file from the media is also parsed. This file (if available) specifies additional commands that will be displayed in the AutoPlay menu. Many companies use this functionality to help initiate their installers.

    Changes

    In order to help prevent malware from spreading (such as Conficker) using the AutoRun mechanism, the Windows 7 engineering team made two important changes to the product:

    1. AutoPlay will no longer support the AutoRun functionality for non-optical removable media. In other words, AutoPlay will still work for CD/DVDs but it will no longer work for USB drives. For example, if an infected USB drive is inserted on a machine then the AutoRun task will not be displayed. This will block the increasing social engineer threat highlighted in the SIR. The dialogs below highlight the difference that users will see after this change. Before the change, the malware is leveraging AutoRun (box in red) to confuse the user. After the change, AutoRun will no longer work, so the AutoPlay options are safe.
      image image
                 Before the Change                                              After the Change
    2. A dialog change was done to clarify that the program being executed is running from external media.
      image image
                  Before the Change                                               After the Change

    It is worth noting that some smart USB flash drives can pose as a CD/DVD drive instead of standard ones (see http://en.wikipedia.org/wiki/U3 for an example). In this specific scenario, the operating system will treat the USB drive as if it is a CD/DVD because the type of the device is determined at the hardware level.

    For further information please visit the Windows 7 blog.

    This change is available in the RC build of Windows 7.We are planning on making this change available on Windows Vista and Windows XP, so that the rest of our customers can benefit from these changes as well.

    Thanks,

    Damian Hasse – MSRC Engineering Blogger

    References:

    Updated on 4/28: Change text to "non-optical removable media" instead of "non removable optical media"

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

  • The MSHTML Host Security FAQ: Part II of II

    MSHTML, a.k.a. Trident, is the Internet Explorer browser rendering engine. MSHTML is a great solution for rendering HTML content, either in the context of a web browser, or simply to display rich UI in an application. You are likely not even aware of some of the many ways MSHTML is hosted within Windows and third party applications. For example, the Windows XP Add/Remove Programs control panel is implemented using MSHTML. Care must be taken in order to host MSHTML with appropriate security. This FAQ will help you avoid making some common MSHTML hosting mistakes.

    MSHTML may be hosted directly or via SHDOCVW. The information in this FAQ applies to either hosting scenario unless otherwise specified.

    How do I make my MSHTML host opt-in to advanced IE security mitigations?

    Internet Explorer 6 SP2 introduced the Feature Control Key (FCK) mechanism enabling advanced browser features to be enabled or disabled on a per-process basis. Some of the features regulated by FCKs are security related, directly or indirectly. Features may be opt-in or opt-out, so your MSHTML hosting process may or may not get them “for free” depending on the settings for individual features. Most FCKs automatically apply to IEXPLORE.EXE and EXPLORER.EXE even if the FCK is not present in the registry.

    Here are opt-in FCKs that you should consider based on their documented functionality:

    Similarly, consider implementing this opt-out FCK:

    Opt-in to FEATURE_PROTOCOL_LOCKDOWN (Network Protocol Lockdown) only if your host has a special need for this feature. Network Protocol Lockdown enables hosts to support per-protocol zone policy. It is not enabled in Internet Explorer by default.

    While it is possible to set FCKs programmatically via CoInternetSetFeatureEnabled, this is not currently supported on some FCKs such as FEATURE_LOCALMACHINE_LOCKDOWN. The registry mechanism for setting FCKs on a per-process basis is preferred.

    What else to I need to worry about in order to securely host MSHTML?

    Trust decisions / spoofing
    If your host displays arbitrary content from the Internet then it is important to allow the user to make valid trust decisions about that content. In Internet Explorer, this is accomplished by enforcing the display of address bar and lock icon UI (aka IE7 Address Bar Protection).

    New windows
    Content running within your MSHTML host can enable new browser windows to be opened. This may be facilitated via links, META REFRESH operations, script, etc. Usually it is not possible to use named window navigation to target a frame within a given MSHTML host, however if your MSHTML enables new browser windows to open, another browser process on the desktop can navigate those windows elsewhere. (Named window navigation can be achieved using the second parameter of window.open, the TARGET attribute on an anchor, etc.) Additionally, if malicious script is running in a window, that script may be able to reach back through window.opener and navigate or inject script into your hosting environment. If you are hosting MSHTML via SHDOCVW you can handle WebBrowser control events to regulate the creation of new windows.

    Protected Mode IE
    Protected Mode IE was made available on Windows Vista and enables the Internet Explorer process to run with restricted privileges. Independent hosting of MSHTML in Protected Mode is not currently supported. By default, your MSHTML instance will be running at the same integrity level as the hosting application (typically Medium integrity). It is important to avoid enabling scenarios where your MSHTML instance would effectively provide a path to elevate out of Protected Mode IE. Read Understanding and Working in Protected Mode Internet Explorer for more guidance in this area.

    General Hosting Considerations
    Consult Reusing MSHTML, Reusing the WebBrowser Control, WebBrowser Customization (Part 1), and WebBrowser Customization (Part 2).

    In your implementation of IDocHostUIHandler::GetHostInfo, be aware of specific DOCHOSTUIFLAG values you should consider opting-in to for security:

    • DOCHOSTUIFLAG_DISABLE_SCRIPT_INACTIVE
    • DOCHOSTUIFLAG_OVERRIDEBEHAVIORFACTORY
    • DOCHOSTUIFLAG_LOCAL_MACHINE_ACCESS_CHECK
    • DOCHOSTUIFLAG_DISABLE_UNTRUSTEDPROTOCOL

    Also be aware that opting-in to some DOCHOSTUIFLAG values such as DOCHOSTUIFLAG_OPENNEWWIN or DOCHOSTUIFLAG_ENABLE_INPLACE_NAVIGATION could potentially enable interesting attack scenarios depending on the overall functionality of the host.

    Avoid situations where your WebBrowser Control host does something explicitly unsafe given the untrusted nature of the web content it is operating on. For example, imagine a DWebBrowserEvents2::BeforeNavigate2 event handler that in some situations calls ShellExecute on the navigation target URL. Since the web content in the host may not be trusted, this essentially would allow malicious HTML to execute code.

    Reference the “Controlling Download and Execution” section of WebBrowser Customization (Part 1) . Specifically, consider opting-in to these flags for security:

    • DLCTL_NO_SCRIPTS
    • DLCTL_NO_JAVA
    • DLCTL_NO_FRAMEDOWNLOAD
    • DLCTL_NOFRAMES
    • DLCTL_NO_DLACTIVEXCTLS
    • DLCTL_NO_RUNACTIVEXCTLS
    • DLCTL_NO_BEHAVIORS

    The following flags may be useful if you are attempting to block external content references (for example, in an e-mail client):

    • DLCTL_PRAGMA_NO_CACHE
    • DLCTL_FORCEOFFLINE
    • DLCTL_NO_CLIENTPULL

    If you are using MSHTML as an HTML previewer, you may want to set DLCTL_SILENT to block dialog boxes.

    A special note on “Elevated Sandbox” hosting scenarios

    The term “elevated” here does not refer to its specific technical meaning in the context of UAC / Protected Mode IE.

    Often we see scenarios where script running within MSHTML is empowered with special abilities. In the case of HTML Help content, it was useful for the HTML Help environment to be able to run system commands, open control panel applets, etc. In cases such as these, barriers are constructed to prevent invasion by arbitrary HTML / script.

    This situation creates an incentive for attackers to “break in” to the MSHTML hosting environment in order to execute arbitrary code or otherwise abuse the special permissions granted to MSHTML. Attacks may attempt to use obscure techniques to navigate the MSHTML host, or inject script via other means.

    This same problem has manifested many times, often resulting in Critical severity patch class vulnerabilities.

    The situation can be especially problematic when the MSHTML host ends up as a development platform in and of itself. Developers may follow the “normal” paradigms for building web sites, and in doing so end up stepping on a variety of landmines:

    • Use of innerHTML to write untrusted input to the DOM
    • Use of document.write to write untrusted input to the DOM
    • Use of Javascript eval on untrusted input
    • Referencing URLs provided as input without validating their protocol scheme
    • Referencing external resources in SCRIPT elements
    • Referencing remote CSS stylesheets
    • …and more. See Inspect your Gadget.

    All of the practices listed above can result in injection issues that would compromise the security of the MSHTML host.

    The HTML development model has evolved in such a way so as to make securing these types of scenarios difficult. As an alternative to hosting MSHTML, consider using a presentation system such as Silverlight or Windows Presentation Foundation (WPF) that provides better separation between markup and code. Otherwise, developers must exercise a greater level of caution when building content for your platform.

    - David Ross, MSRC Engineering

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

  • The History of the !exploitable Crash Analyzer

    At the CanSecWest conference earlier this month we made our first public release of the !exploitable Crash Analyzer. While an upcoming white paper and the CanSecWest slide deck go into detail on the technology involved, we thought it might be useful to explore the history of the tool.

    Roots in Fuzzing

    The technology and research that eventually became the !exploitable Crash Analyzer came out of the investment that MSEC (and Microsoft as a whole) has made in fuzzing technology. Preceding the launch of Windows Vista, there was a 14 month fuzzing effort totaling over 350 Million iterations. Upon examining crashes from the fuzzing effort, a number of observations were made about similarities in crashes. Several folks from what is now MSEC (Adel Abouchaev, Damian Hasse, Scott Lambert and Greg Wroblewski) published an article regarding some of these findings in the November 2007 edition of MSDN.

    One of the nice benefits of fuzzing is that it eliminates any need to determine “is the problematic code reachable by an attacker”. Because the malformed data is provided in the same way that an attacker would provide it, we know that if we are able to generate an issue during fuzzing, a real attacker would in all likelihood be able to reach the same code.

    Another observation was that a single issue in code could be reached via multiple vectors, creating crashes that appeared to be different, but with the same root cause. By grouping crashes together which occur in the same area of code, the number of crashes that need to be looked at can be dramatically decreased.

    In the diagram below, we’ve seen the results from 2 weeks of fuzzing with 4 different fuzzers against 1 parser, which found 57 crashes, and VERY LITTLE overlap between fuzzers:

    image

    When the same 57 crashes are run through !exploitable Crash Analyzer, and grouped for similarity, we see that there are 15 unique issues, reducing the number of crashes to look at nearly 4-fold, and Fuzzers A and B found all but 2 of the issues, showing what fuzzers really give the best coverage for this application.

    image

    However, even when grouping similar crashes, there is a need to perform a rough-cut triage of the severity of the crashes found. The !exploitable Crash Analyzer was built to address these needs. Because of this, the tool assumes that the information in the faulting instruction is controlled by an attacker – the normal case when assessing results of fuzzing runs.

    Implications when applied to other crashes

    Once we move beyond fuzzing, the assumptions built into the tool make the results less reliable. Unlike our fuzzer generated crashes, we don’t actually know whether the crash was caused by information that could be controlled by an attacker. Even in this case, the stack trace hashes let us group similar issues. But we have to add an implicit caveat to the exploitability ratings provided by !exploitable: “If an attacker controlled the source data to the faulting instruction…”.

    What does this mean for the developer? Effectively, it means that we don’t know whether or not we simply have a problematic coding issue or bug versus a true security vulnerability. A coding issue or bug becomes a security vulnerability only when an attacker is able to reach it, generally by providing invalid data. It may be that the problematic code cannot be reached by an attacker, in which case we merely have a bug. It may be that there are code paths (which we may or may not have found) that expose the problematic code to attacker controlled data. Or it may be that a yet to be implemented feature will expose the issue. But for the software developer, especially when these coding issues are found early in development, the knowledge that there is a potentially problematic issue in the code should be enough to get the fix created and implemented or made available for users to install as appropriate.

    How Exploitable is Exploitable?

    Even in the cases where the crash was caused by data supplied by an attacker, we don’t know how much control the attacker has. For example, if we look at a faulting memory copy, it’s possible that the attacker could control the destination address, the source address, the move length, or some combination of all three. Inside of the !exploitable Crash Analyzer, we assume that the attacker has control of all three. While this is probably not the case, we are willing to accept the over-assessment of risk in this case because the coding issue is considered severe enough that the ensuing false positive rate is something we consider acceptable.

    When analyzing a crash, !exploitable is looking at the details, and categorizing the severity based on reasonably coarsely grained heuristics. You can read the output of !exploitable as “This is the sort of crash that experience tells us is likely to be exploitable”, and for the software developer, that should be all of the information that is necessary. It’s well beyond the scope of the tool to figure out how an exploit could be delivered; that sort of analysis tends to require highly skilled humans.

    Moreover, even in the case where a vulnerability is exploitable, exploit mitigations built into the compiler and the platform may be sufficient to prevent actual exploitation. This doesn’t mean that the root problem shouldn’t be fixed, any more than having airbags and wearing your seatbelt means it is acceptable to not repair your brakes. But it does mean that sometimes the end user is protected, even if everything else went wrong.

    The Target Audience

    Fundamentally, this is a defensive tool, aimed at the software developer, especially those without deep expertise in security threats. By grouping common issues, identifying cases where multiple code paths flow to the same underlying issue, and providing a rough cut of the security implications of individual crashes, we think it provides a valuable service to software developers triaging bugs during development. We’ve certainly found that to be the case inside of Microsoft.

    Dave Weinstein and Jason Shirk
    Microsoft Security Engineering Center

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

  • Investigating the new PowerPoint issue

    This afternoon, we posted Security Advisory 969136 describing a new vulnerability in PowerPoint while parsing the legacy binary file format. Unfortunately, we discovered this vulnerability being used to deploy malware in targeted attacks. We expect this blog post will:

    • Help you protect your organization from being exploited, and
    • Help you analyze suspicious PowerPoint files.

    The malware samples we have seen exploiting this vulnerability are the first reliable exploits we have seen in the wild that infect Office 2003 SP3 with the latest security updates. Office 2003 SP3 (released Sept 2007) had a good run being safe from the bad guys but we missed this bug while back-porting fixes found in the Office 12 fuzzing effort to Office 2003 SP3. SP3 was a massive security push that we recommend all Office 2003 customers apply (this vulnerability notwithstanding).

    There are a couple workarounds you can apply in your environment to protect yourself from potential attacks using this vulnerability. First, the vulnerable code cannot be reached by PowerPoint files in the newer XML file format. If your environment has mostly already migrated to using PPTX, you can temporarily disable the binary file format in your organization using the FileBlock registry configuration described in the security advisory. Alternatively, you can temporarily force all legacy PowerPoint files to open in the Microsoft Isolated Conversion Environment (MOICE). The steps to enable MOICE are listed in the advisory. In addition to the defense-in-depth sandbox MOICE uses during the conversion, the PowerPoint converter is not vulnerable to this bug so it is safe to use MOICE to "wring out" the unsafe record configuration.

    Finally, we wanted to share some tricks to analyze exploits we have seen for this vulnerability. If you have access to any of the samples listed in the MMPC blog post, you can follow along with this mini tutorial to extracting trojans from targeted attacks.  This is a dynamic analysis method that does not even require you to recognize assembly.  However, you will need a vulnerable version of Office (Office 2003 SP3 in this case) and WinDbg.

    Start by setting the Image File Execution Option to set a default debugger for “POWERPNT.EXE”:

    • Start->Run->Regedit.exe
    • Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
    • Create a new key called “powerpnt.exe” (no quotes)
    • Click on the new “powerpnt.exe” key and create a new REG_SZ value for called “Debugger” and set its value to “windbg.exe” (make sure you have windbg.exe in your PATH)

    Next, double click on the malicious PowerPoint file. You will see the WinDBG window pop up asking you for commands. Set these breakpoints:

    • bp kernel32!CreateFileW ".printf \"CreateFileW(\%mu) RetAddr 0x\%08x\\n\", poi(esp+0x4), poi(esp);dds esp L1; g"
    • bp kernel32!CreateFileA ".printf \"CreateFileA(\%ma) RetAddr 0x\%08x\\n\", poi(esp+0x4), poi(esp);dds esp L1; g"
    • bp kernel32!LoadLibraryW ".printf \"LoadLibraryW(\%mu) RetAddr 0x\%08x\\n\", poi(esp+0x4), poi(esp);dds esp L1"
    • bp kernel32!LoadLibraryA ".printf \"LoadLibraryA(\%ma) RetAddr 0x\%08x\\n\", poi(esp+0x4), poi(esp);dds esp L1"
    • bp kernel32!WinExec ".printf \"WinExec(\%ma) RetAddr 0x\%08x\\n\", poi(esp+0x4), poi(esp);dds esp L1"

    This causes the relevant parameters from CreateFile, LoadLibrary, and WinExec to be printed out as they are called. This way, we will be able to see which files the exploit creates, with complete path. Eric Landuyt from DataRescue employed this method to analyze a piece of malware (Hi Eric!). In our scenario, we apply it to shellcode. We also set a breakpoint on “WinExec” because we know that this particular shellcode will use WinExec to execute the trojan file. Sometimes shellcode uses CreateProcess instead. It is important to note that we did not put a “g” for the WinExec breakpoint because we do not want it to execute. We just want the path. To continue the process, hit “g” to let PowerPoint execute. Now, you will see a lot of messages coming up on the screen because PowerPoint actually uses CreateFile/LoadLibrary for legitimate purposes; the shellcode will use it too, but it will be towards the end. Here is an example output:

    0:000> g
    CreateFileA(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c802039
    00133598  7c802039 kernel32!GetStartupInfoA+0x14b
    CreateFileW(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c801a4f
    00133574  7c801a4f kernel32!CreateFileA+0x2b
    WinExec(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c802039
    001335ac  7c802039 kernel32!GetStartupInfoA+0x14b
    eax=7c86114d ebx=7c802039 ecx=00000000 edx=7c802039 esi=001860f8 edi=001861f8
    eip=7c86114d esp=001335ac ebp=00186087 iopl=0         nv up ei pl nz na po nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200202
    kernel32!WinExec:
    7c86114d 8bff            mov     edi,edi
    0:000> 

    It is easy to see from the output where the trojan was placed. You are at a breakpoint now so you can safely grab the malicious EXE file and perform whatever analysis you'd like.

    Sure enough, ~AC0810.TMP is a malicious PE binary:

    You can apply this same fast, simple, generic technique in analyzing EXE malware, PDF, IE, and other types of exploits. Let us know if you have feedback or other analysis techniques you would like to share.

    - Bruce Dang and Jonathan Ness, MSRC Engineering

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

     Update (April 3, 2009): Minor edit to the LoadLibrary breakpoint commands.  Thank you to Julio Auto for pointing this out.

  • MS09-014: Addressing the Safari Carpet Bomb vulnerability

    Following up on Security Advisory 953818, today we released MS09-014, rated as Moderate, which addresses aspects of the Safari Carpet Bomb vulnerability. On a Windows operating system this vulnerability allows an attacker, through Safari, to drop arbitrary files on a user’s desktop. As of Safari 3.1.2 Apple has removed this behavior from Safari.

    Why is Microsoft releasing a Bulletin?

    While Microsoft code may not have been involved in dropping files on the desktop, there are publicly available exploits that leveraged Microsoft code. Specifically, this was done through the use of Internet Explorer.

    Internet Explorer uses the user’s desktop for its current working directory. Both the LoadLibrary and SearchPath APIs use the current working directory when searching for files. As a result of this Internet Explorer would attempt to load certain libraries directly from the desktop. The exploits took advantage of this by using Safari to place carefully crafted libraries on the user’s desktop, which then caused Internet Explorer to run arbitrary code.

    Even though the ability to drop arbitrary files on the user’s desktop has been removed from Safari, we wanted to further protect users by preventing IE from using the libraries involved in the exploit. This was done by changing several calls to LoadLibrary and SearchPath in Internet Explorer.

    Additional Defense in Depth Protections

    In addition to making the code changes, we realize that IE is a highly extensible platform. It uses many different libraries and hosts a large number of different components, many of which are developed outside of Microsoft. To help protect these components from exploitation, we have put together some other defense in depth protections.

    Part of these protections involves removing the current working directory from the LoadLibrary search path. In order to do this without impacting other processes, the SetDllDirectory API is used. In particular, IE calls SetDllDirectory with an empty string (“”). Another part of the protections involves changing the order in which SearchPath searches directories. A new API called SetSearchPathMode has been created and allows IE to force the current directory to be searched after the system locations. As with SetDllDirectory, SetSearchPathMode does not impact processes outside of IE.

    Unfortunately, the application compatibility tests we perform with each update have indicated that these protections have the potential to break consumer applications. We cannot enable the protections by default without causing problems for some customers and have elected to ship the update with them turned off. For users and enterprises who wish to enable the protections, this can be done by setting the feature control key listed in the security bulletin under “Frequently Asked Questions (FAQ) Related to This Security Update” (http://www.microsoft.com/technet/security/bulletin/ms09-014.mspx#ERIAC). Before turning them on, you should test to ensure they do not prevent applications in you environment from working correctly.

    As a final comment, you should be aware that even with these protections in place, it is possible, in certain circumstances, to load a library from the current directory. This can happen for code that uses SearchPath to locate libraries and later uses LoadLibrary to load what SearchPath found. In this situation a library can get loaded from the current directory if the library is not present at any location in the system path. This happens because SearchPath checks the current directory as a last resort when locating files. We were unable to address this with the additional defense in depth protections as the SearchPath API is intended to locate user documents and legitimately should search the current directory. Developers are advised not to use Search to locate libraries and instead should rely on LoadLibrary to find them. This is covered in more detail in the following section.

    Notes for Developers

    For developers who wish to avoid similar problems, there are two key things that can be done to help prevent libraries from being loaded form the desktop:

    • Do not use SearchPath to locate libraries that you intend to load with LoadLibrary. SearchPath follows a different path search order than LoadLibrary when locating files. The search order it follows by default is intended for user documents and is insecure for locating libraries. This warning is reflected in the MSDN pages for both LoadLibrary and SearchPath. For developers that need to find that path where a library is loaded from, you can use GetModuleFileName after calling LoadLibrary.
    • If the DLL you are loading does not always exist on the system, use a fully qualified path to prevent your code from inadvertently loading a malicious copy. To help generate fully qualified paths, you can use the ExpandEnvironmentStrings function in conjunction with strings such as %WINDIR% and %PROGRAMFILES%.

    By following these two rules, it is possible to prevent your code from inadvertently loading a library from the current working directory.

    As with all our updates, we recommend applying this update as soon as possible.

    -SRD Bloggers

    Update April 15th: URL corrected thanks to reader Frank Zieman for pointing this out.

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

  • MS09-012: Fixing “Token Kidnapping”

    This morning we released MS09-012, an update to address the publicly-disclosed issue commonly referred to as Token Kidnapping (http://www.argeniss.com/research/TokenKidnapping.pdf). This vulnerability allows escalation from the Network Service account to the Local System account. Normally malicious users are not running as Network Service, except for a very few programs like IIS, where arbitrary code can be executed within a service running as Network Service. This allows malicious users to attack and gain control of Windows.

    Am I vulnerable?

    This issue affects scenarios where untrusted code is being executed within a process owned by the Network Service account, or within processes having the SeImpersonatePrivilege. The publically discussed attack is via malicious Full Trust ASPX code hosted within an IIS worker process. Normally untrusted users aren't allowed to add web content to an IIS website, but some web hosts explicitly offer hosting for 3rd party web content. You can read more about the risk in a previous SRD blog entry here: http://blogs.technet.com/srd/archive/2008/10/13/service-isolation-explanation.aspx

    Background

    Addressing this issue required one of the most epic engineering efforts we have ever expended for a Microsoft security update. This security update changed parts of the Windows kernel; the COM, DCOM, and LSASS subsystems; the WMI and MSDTC built-in services; and the service control manager (SCM). We had to back-port much of the service token work implemented in Vista and Server 2008 down to XP and Server 2003. Some of our most senior developers and architects devoted time away from Windows 7 development to address this issue down-level. (Security updates are typically fully handled by the Sustained Engineering team.) The changes made were in sensitive parts of the OS which required some delicate re-architecture work to avoid application compatibility issues, which took a long time to plan and develop. Then we wanted to be absolutely sure we wouldn’t break anything after changing these core pieces of the Windows architecture so this update went through rigorous testing to iron out the issues testing uncovered. Only now is it finally ready to be released.

    We’d like to answer a few questions you might have about this security update.

    Why are there multiple different CVE’s being addressed in this update?

    To address this issue system-wide, we actually needed to fix four separate vulnerabilities. You can see more detail about each of the separate CVE’s below.

    CVE-2008-1436 for MSDTC:

    One of the issues publically identified was a flaw in MSDTC. It was asking for too much permission when creating an RPC connection. A higher privilege token would then be created in the process calling RPC allowing that process to elevate and execute as the Network Service account. This update addresses the issue by having MSDTC ask for less permissions when creating the RPC connection so the user's process doesn't receive this higher privilege token.

    CVE-2009-0079 for RPCSS:

    The second piece which needed updating involved the security permissions given to various services running as the Network Service account. This update backports a subset of Vista's Service SID functionality, discussed here by Mark Russinovich (http://technet.microsoft.com/en-us/library/cc748650.aspx); thus this update is not applicable in Vista and Windows Server 2008. This helps prevent services running as Network Service from attacking the RPCSS service. Additionally it lays the framework for future services to be opted into the Service SID functionality should the need arise on these older versions of Windows. All services were not configured to run with a Service SID down-level due to application compatibility concerns and technical limitations.

    CVE-2009-0080 for the Thread Pool:

    The third issue brought up was an attack which would cause a new thread to be created in a given process. This thread wouldn't require the proper permissions to open it, which created this possibility for attack. The fix was to harden the permissions required to access the thread.

    CVE-2009-0078 for WMI:

    And finally, WMI previously ran Network Service and Local Service providers without any protection from other processes running under the same account. The WMI changes use technology based from Vista's Service SID functionality to protect WMI providers with a WMI SID. Third parties will need to evaluate their WMI providers and opt into this functionality if applicable.

    The Future

    In the upcoming release of Windows 7 and Windows Server 2008 R2 systems, a new feature named Managed Service Accounts (http://technet.microsoft.com/en-us/library/dd367859.aspx) has been introduced which creates a more streamlined and flexible solution to the issues surrounding service isolation. It provides for services, which have opted to use the feature, the ability to run as a separate account which remotely authenticates with a managed domain SPN. It also provides seamless and automatic password management, similar to the computer account, which frees up time that administrators would previously have used to update user account passwords for these services. You can read more about creating Managed Service Accounts here http://technet.microsoft.com/en-us/library/dd548356.aspx.

    - Nick Finco, MSRC Engineering

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

  • MS09-013 and MS09-014: NTLM Credential Reflection Updates for HTTP clients

    This month we are taking another step towards blocking NTLM reflection attacks by releasing MS09-014 for Internet Explorer and MS09-013 for Windows. This is the third update related to NTLM credential reflection we have released, and I thought it would be good to go into a bit more detail on why this update was needed, how it relates to the previous updates (MS08-068 and MS08-076), and the severity of the issue.

    Background on the prior updates:

    In November 2008, we released an update for SMB that prevented so-called “SMB Reflection” attacks. These attacks target the SMB protocol used for file and printer sharing, and allow an attacker to gain access to a victim’s machine with the same rights as the logged-on user. If the user has administrator permissions, then the attacker can take complete control of the victim’s machine. (For more details see the previous blog entry on MS08-68 here. The history of this issue is covered on the MSRC blog here).

    The MS08-068 update protected SMB from this attack by causing the SMB client in Windows to opt-in to the reflection protections that NTLM offers. This allows the NTLM sub-system to detect when challenge values are replayed to the same machine, and fail the attacker’s authentication.

    The MS08-076 update fixed a similar issue in the Windows Media components.

    This month’s HTTP update:

    Other protocols support sending NTLM credentials. For each protocol that has valid attack vectors, we have been working for some time on updates that block reflection attacks. This is a complex process involving changes that affect widely-used protocols and risk application compatibility, so rigorous testing was needed.

    In the case of HTTP, Internet Explorer supports sending NTLM credentials automatically over HTTP when communicating with a web-server in the Intranet zone. This has been used in external tools to perform cross-protocol attacks as follows:

    • The victim connects to the attacker’s web-server
    • The attacker’s machine initiates an SMB connection to the victim
    • The attacker forces the victim’s browser to respond to the SMB connection’s request for authentication using NTLM.

    The reason this attack works even with MS08-068 installed is that the client performing NTLM authentication in this case is HTTP, not the SMB client. The updates we are shipping this month block the above attack by making the HTTP client APIs correctly opt-in to NTLM reflection protections.

    Issue Severity:

    Note that attacks targeting this issue only work in the Intranet zone – Internet Explorer will not send credentials automatically in the Internet zone. This limits attacks to coming from within the same subnet or from the same internal network. Possible attackers in be “malicious insiders” or machines that were compromised using an unrelated security vulnerability.

    For the attack to lead to a compromise of the target, SMB traffic must also be allowed inbound. This mean hosts that are behind firewalls that block SMB traffic, or that block it at the host firewall, will not be vulnerable to the most common NTLM reflection attacks that target SMB.

    Machines that are not joined to a domain are also less vulnerable to this attack due this setting which forces local users to authenticate as the Guest user on the network.

    Summary:

    It should now be clear that MS08-068 and this month’s update are part of a larger effort to secure NTLM against reflection and replay attacks. There is more work to do before we can say we have truly solved the problem, and future updates will continue to improve the security of our products in this respect.

    - Mark Wodrich, MSRC Engineering

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

  • The MSHTML Host Security FAQ: Part I of II

    MSHTML, a.k.a. Trident, is the Internet Explorer browser rendering engine. MSHTML is a great solution for rendering HTML content, either in the context of a web browser, or simply to display rich UI in an application. You are likely not even aware of some of the many ways MSHTML is hosted within Windows and third party applications. For example, the Windows XP Add/Remove Programs control panel is implemented using MSHTML. Care must be taken in order to host MSHTML with appropriate security. This FAQ will help you avoid making some common MSHTML hosting mistakes.

    MSHTML may be hosted directly or via SHDOCVW. The information in this FAQ applies to either hosting scenario unless otherwise specified.

    The MSHTML Host Security FAQ – Part I

    How do I evaluate the level of risk posed by my MSHTML hosting scenario?

    Here’s how to quickly evaluate the risk of any MSHTML hosting scenario:

    Risk level 3: No arbitrary content
    There is low risk when MSHTML is simply displaying static content loaded from a local source (Ex: A resource file, HTML on the local drive, etc.). That is not to say there is zero risk. For example, think about any possibility that an attacker may force navigation of the host somehow, perhaps using a command line parameter passed via a registered protocol handler.

    Risk level 2: Controlled content
    It is possible to lock a MSHTML instance to a single site. However, when this is implemented without SSL, MitM (Man-in-the-middle) or DNS poisoning attacks can enable execution of script within the hosted MSHTML instance.

    Even when SSL is used (and the certificate is validated), it can still be problematic to ensure that content rendered only comes from an “unhackable” / bulletproof site. Even if the source were secure, content coming from the source still should not have authorization to automatically execute arbitrary code on the user’s machine. This is in line with the general security principal of least privilege.

    Really, all content should execute securely within the hosted MSHTML instance, no matter where the content appears to have originated. That being said, if the content source is locked down sufficiently, this does at least serve as a mitigating factor for potential vulnerabilities.

    Risk level 1: Fully arbitrary content
    In this case, the MSHTML host should not take any shortcuts in enforcing the same security as is applied within the Internet Explorer web browser. Otherwise, attacks may be possible within the MSHTML host that wouldn’t otherwise be possible within Internet Explorer.

    One mitigating factor may be that the navigation would have to occur within the MSHTML host. For example, using Visual Studio to navigate to web sites is not a very common usage scenario. If the Visual Studio MSHTML host has a vulnerability, it may not be very practical to exploit. Still, clearly it must not be possible for web content within Visual Studio’s MSHTML instance to run arbitrary code, read local files, etc.

    Risk level 0: Fully arbitrary content available “zero-click” from e-mail or the web
    As an example, imagine a media player were to host MSHTML and allow arbitrary navigation. If certain security restrictions were in place in the browser but not in the media player hosting scenario, these restrictions could be immediately circumvented. (A media file presumably could cause the media player's MSHTML instance to navigate to an arbitrary web site.) Web browsers serve as the vector for many real-world attacks so this is a compelling attack scenario that must be avoided.

    How do I offer advanced functionality to HTML within my hosting environment, safely?

    It is often desirable to expose some special functionality to content running within the hosted MSHTML instance. Heed the guidance in the “Elevated Sandbox” section in Part II of the FAQ and resist the temptation to enable unsafe behavior (execution of arbitrary system commands, etc.) within your MSHTML instance.

    Some of the common MSHTML extensibility mechanisms include:

    • Window.external
      It is possible to extend the DOM via window.external. An example of this would be a CD burning application that presents its user interface using MSHTML. This application could enable the user interface to trigger the CD burning functionality by exposing a method BurnToCD() off of window.external. For more information on the window.external extensibility mechanism, see: http://support.microsoft.com/kb/188015. The general security guidance above applies to this extensibility mechanism.
    • ActiveX
      It is possible for an ActiveX control to only operate, or to provide extra functionality, when hosted within a specific MSHTML environment. As an example, HTML Help provides an ActiveX control that enables some functionality only when hosted within HH.EXE. If you implement a similar solution, make sure that the special functionality is exposed only within your MSHTML host. One way to do this would be to validate the hosting process’s name. In this way you can avoid having your functionality unintentionally abused within the context of another application.

      There are ways to host an ActiveX control such that it is impossible for it to identify the URL of its hosting page (Ex: Exploits for the vulnerability fixed in MS06-04 used this kind of technique). So when developing your control, make sure it is capable of falling back to a secure state if it cannot positively identify its hosting environment. The SiteLock Template for ActiveX controls is secure against this threat.
    • Templates
      It is common for applications to load HTML template files and fill in information from other sources before passing the resulting HTML on to MSHTML to render. For example, imagine a media previewer that extracts metadata from an MP3 file and plugs that metadata into a template that will then be displayed to the user via MSHTML. If your host implements a similar strategy, be aware of potential injection issues. Do not allow Script / HTML / ActiveX controls to be injected into your MSHTML host. Inspect your Gadget includes tips on how to mitigate this class of issue in your HTML templates. (Much of the guidance around Vista Sidebar Gadgets applies equally to templates.)

    How can my MSHTML host regulate the security policy applied by IE Security zones?

    By default, MSHTML regulates security policy based on the calculated zone of the page it is rendering. This is often an issue for MSHTML hosts because while the model may make sense for the Internet Explorer browser, it doesn’t necessarily map to the MSHTML host’s security model unless care is taken.

    Imagine a news reader application that downloads HTML to the local hard drive and then navigates a MSHTML instance to this downloaded content. Data from the Internet is now likely to render within the Local Machine Zone. Within the Local Machine Zone, the content has access to unsafe functionality enabling the execution of arbitrary code. In the browser, this may have been mitigated by Local Machine Zone Lockdown, however this would not apply to the news reader by default unless it were to opt-in to the appropriate Feature Control Key (FCK). To ensure application compatibility, Local Machine Zone Lockdown is not enabled for all MSHTML hosts by default.

    The example above demonstrates why it is very important to understand the security policy applied by Internet Explorer Zones when a page is rendered within your MSHTML hosting environment.

    Implementing a Security Manager
    The default Internet Explorer security policy very well may make sense for your MSHTML host. However, if it does not, be sure to implement a security manager. The browser policy that may be enforced using a security manager is a superset of what is available in the advanced zone options in Internet Explorer:

    image

    For example, a security manager can allow your host to disable all script yet only allow one specific ActiveX control to run. The policy flags that can be controlled from a security manager are called URL Actions and are defined in urlmon.h. Be aware that even if your security manager blocks script and ActiveX by default, there are likely other URL Actions to consider disabling. For example, your host may disable frames and active content, but without also disabling URLACTION_HTML_META_REFRESH it will still be possible for HTML to trigger automatic navigation.

    Regardless of whether or not you implement a security manager, you may want to implement an Asynchronous Pluggable Protocol Handler (APP). It is possible for an APP to implement IInternetProtocolInfo and provide support for PARSE_SECURITY_URL and PARSE_SECURITY_DOMAIN in order to control the zone into which URLs are placed.

    When implementing an APP for your Trident host, avoid registering it globally on the system if at all possible. Instead, load it dynamically at runtime only for your process. Registering it globally adds unnecessary attack surface to Internet Explorer. See “About Pluggable Protocols” here.

    - David Ross, MSRC Engineering

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

  • MS09-010: Reducing the text converter attack surface

    MS09-010 addresses vulnerabilities in Word converters used by WordPad and by Office to load files saved in old file formats. Some of you probably saw this bulletin and thought “I never open documents from versions of Word prior to Word XP,” and you may be interested in reducing your attack surface. In this post we’ll show you how to disable any converters that you might have on your machine that you don’t anticipate using, as well as how to prevent a particular converter from being inadvertently installed (this can be handy if you manage a number of computers and you want to reduce their attack surfaces).

    How to disable a converter that’s already installed

    The idea is to alter the Access Control List (ACL) so that the Everyone group is denied every permission on the file the converter lives in. This is reversible by the owner of the file, since the owner can always change the ACL of a file regardless of what the ACL currently says.

    A quick note about the difference in the XP and Windows Vista steps: In XP we don’t have icacls, so we can’t backup the ACL before locking it down. However, this should not be a problem for these converters since they don’t typically have an Access Control Entry (ACE) for the Everyone group. If they did have such an ACE, it would be overwritten by our everyone:N ACE, and subsequently removed entirely during the re-enable steps below. Thus, if using Windows XP and in doubt, please double check the ACL and perform a manual backup of it. You can do this by using the /S switch of cacls.exe to export and re-import the SDDL representation of the permissions.

    Note: You will need administrator privileges to set these file restrictions.

    For Windows XP

    cacls CONVERTER_PATH_AND_FILE_NAME /E /P everyone:N

    For Windows Vista (from an elevated command prompt)

    takeown /f CONVERTER_PATH_AND_FILE_NAME
    icacls CONVERTER_PATH_AND_FILE_NAME /save PATH_AND_NAME_OF_FILE_TO_BACKUP_ACL_STATE_TO
    icacls CONVERTER_PATH_AND_FILE_NAME /deny everyone:(F)

    NOTE: CONVERTER_PATH_AND_FILE_NAME refers to one of the converters on the table below.

    How to re-enable a converter that you’ve disabled

    Note: You will need administrator privileges to set these file restrictions.

    For Windows XP

    cacls CONVERTER_PATH_AND_FILE_NAME /E /R everyone

    For Windows Vista (from an elevated command prompt)

    icacls CONVERTER_PATH /restore PATH_AND_NAME_OF_FILE_TO_RESTORE_ACL_STATE_FROM

    How to prevent a converter from being inadvertently installed

    If a system doesn’t have a particular converter installed, we can prevent users of that system from accidentally installing it. We’ll do that by creating a placeholder file in the same folder and with the same name as the converter in question. Then we’ll restrict the ACL just like we did for an installed converter. This prevents the setup program from installing the converter.

    Note: You will need administrator privileges to set these file restrictions.

    For Windows XP

    md CONVERTER_PATH
    echo Placeholder > CONVERTER_PATH_AND_FILE_NAME
    cacls CONVERTER_PATH_AND_FILE_NAME /E /P everyone:N
    

    For Windows Vista (from an elevated command prompt)

    md CONVERTER_PATH
    echo Placeholder > CONVERTER_PATH_AND_FILE_NAME
    icacls CONVERTER_PATH_AND_FILE_NAME /deny everyone:(F)

    How to allow a converter to be installed after going through the steps to disable its installation

    Note: You will need administrator privileges to set these file restrictions.

    For Windows XP

    cacls CONVERTER_PATH_AND_FILE_NAME /E /R everyone
    echo y| del CONVERTER_PATH_AND_FILE_NAME
    

    For Windows Vista (from an elevated command prompt)

    icacls CONVERTER_PATH_AND_FILE_NAME /remove everyone
    echo y| del CONVERTER_PATH_AND_FILE_NAME

    A list of converters

    Here is a list of some converters with their filenames in case you decide to reduce your attack surface by disabling some of them:

    Note: multiple paths are given for these converters – which one applies to your computer depends on what OS version and architecture you are running on, as well as your OS upgrade history.

    What it converts The path and file name
    WordPerfect 5.x "%ProgramFiles%\Common Files\Microsoft Shared\TextConv \wpft532.cnv”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\wpft532.cnv”
    WordPerfect 6.x "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\wpft632.cnv”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\wpft632.cnv”
    Word 6 "%ProgramFiles%\Windows NT\Accessories\mswrd6.wpc"
    "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\mswrd632.wpc"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\mswrd632.wpc"
    "%ProgramFiles%\Windows NT\Accessories\mswrd664.wpc"
    "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\mswrd632.cnv"
    "%ProgramFiles(x86)%\Windows NT\Accessories\mswrd6.wpc"
    Word 97 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\mswrd832.cnv"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\mswrd832.cnv"
    "%ProgramFiles%\Windows NT\Accessories\mswrd8.wpc"
    "%ProgramFiles%\Windows NT\Accessories\mswrd864.wpc"
    "%ProgramFiles(x86)%\Windows NT\Accessories\mswrd8.wpc"
    Word 97-2000 & 6.0/95 RTF files "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\Wrd6er32.cnv”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\Wrd6er32.cnv”
    Works 4 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\works432.cnv"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\works432.cnv"
    Works 6 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\Works632.cnv"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\Works632.cnv"
    Works 7-9 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\wkcvqd01.dll”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\wkcvqd01.dll”
    "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\wkcvqr01.dll”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\wkcvqr01.dll”
    HTML32 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\html32.cnv”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\html32.cnv”
    “%SystemRoot%\SYSTEM32\HTML.IEC”
    MSCONV97 "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\MSConv97.dll”
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\MSConv97.dll”
    Write "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\write32.wpc”
    "%ProgramFiles%\Windows NT\Accessories\write.wpc"
    "%ProgramFiles(x86)%\Windows NT\Accessories\write.wpc"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\write32.wpc"
    "%ProgramFiles%\Windows NT\Accessories\write64.wpc"
    Recovr32.cnv "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\Recovr32.cnv"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\Recovr32.cnv"
    WpEqu532.dll "%ProgramFiles%\Common Files\Microsoft Shared\TextConv\WpEqu532.dll"
    "%ProgramFiles(x86)%\Common Files\Microsoft Shared\TextConv\WpEqu532.dll"

    An example to work from

    Disabling the wpft532.cnv converter on Windows Vista:

    C:\>takeown /f "C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV"
     
    SUCCESS: The file (or folder): "C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV" now owned by user "Foo\Bar".
     
    C:\>icacls "C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV" /save %admintemp%\WPFT532_ACL_BACKUP.txt
    processed file: C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV
    Successfully processed 1 files; Failed processing 0 files
     
    C:\>icacls "C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV" /deny everyone:(F)
    processed file: C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV
    Successfully processed 1 files; Failed processing 0 files
    

    Re-enabling the converter (note that we don’t supply the filename, just the path, to where wpft532.cnv is stored):

    C:\>icacls "C:\Program Files\Common Files\microsoft shared\TextConv" /restore %admintemp%\WPFT532_ACL_BACKUP.txt
    processed file: C:\Program Files\Common Files\microsoft shared\TextConv\WPFT532.CNV
    Successfully processed 1 files; Failed processing 0 files
    

    A note about Group Policy

    You can also disable converters that are already installed via group policy, and re-enable them again as well. The idea is the same as the manual steps listed above:

    • To disable the converter, add a Deny Everyone Full Control access control entry to the file for the converter you wish to disable.
    • To re-enable the converter, remove the entry for the Everyone group.

    You can find specific instructions on how to apply these changes via group policy here: http://technet2.microsoft.com/windowsserver/en/library/1687ef1d-b382-49c7-b184-a4cc888be5251033.mspx?mfr=true

    MOICE

    After locking down converters on your system, if you decide you want to open a file from an old program – consider using MOICE to open it instead. It converts the file to the Office 2007 format, and does so in an isolated environment which makes it less likely that malicious file could cause harm. Read more about MOICE and download it from here: http://support.microsoft.com/kb/935865

    We hope you’ve found this post helpful in reducing the attack surface of your machines.

    - Kevin Brown, MSRC Engineering

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

  • Prioritizing the deployment of the April security bulletins

    We just released eight security bulletins, five of which are rated Critical on at least one platform. We built a reference table of bulletin severity rating, exploitability index rating, and attack vectors. This table is sorted first by bulletin severity, next by exploitability index rating, and then by bulletin number. We hope it helps you choose an order of bulletins to start your prioritization and testing if you can’t deploy them all out immediately.

    Bulletin Highest bulletin severity Highest Exploitability Index Rating Any vulns known to be public-known? Attack vector for code execution / Notes
    MS09-009 Critical High (1) Yes, CVE-2009-0238 known to be exploited already. XLS file attached to email or posted on a website. These vulnerabilities are critical only on Office 2000. Other versions of Office force user to click through a prompt, reducing severity to Important.
    MS09-010 Critical High (1) Yes, CVE-2009-0235 known to be being exploited already. RTF, WRI, or DOC file attached to email or posted on a website. Blog entry with more details about Converter Attack Surface here.
    MS09-013 Critical High (1) Yes, exploit tools are publicly available for CVE-2009-0550 (SMBRelay). However, this CVE is Important, not Critical. The attack vector for the Critical CVE is a client-side application uses WinHTTP to generate a network-based request to a malicious server. The malicious server responds with a malformed request causing either a client-side application crash or code execution in the context of the user running the application. Internet Explorer does not use WinHTTP.
    MS09-014 Critical High (1) Yes, CVE-2008-2540 is known externally. However, it is rated “Moderate”. This bulletin also addresses a portion of CVE-2009-0550, mentioned above.

    The attack vector for the Critical CVEs would be Internet Explorer connecting to a malicious website.

    You can read more about how we fixed the public CVE-2008-2540 (Safari Carpet Bombing) here.

    MS09-011 Critical Medium (2) No. AVI file attached to email or webpage pointing you at an AVI file.
    MS09-012 Important High (1) Yes, exploit tool publicly available. After an attacker compromises an IIS-hosted web application, they could use these vulnerabilities to escalate to SYSTEM.  You can read more about how we fixed this vulnerability here.
    MS09-016 Important Low (3) Yes, limited details of this vulnerability are known externally No threat of code execution.
    MS09-015 Moderate Medium (2) Yes. No known attack vector.

    We would be happy to answer any questions you have about these bulletins. You can contact us at switech _AT_ microsoft.com. We will also be on the monthly MSRC webcast that describes the bulletins and answers questions live "on air". You can find instructions to attend that webcast on the MSRC blog.

    Update April 15: Revised MS09-015 max exploitability index rating to "2".  Thanks reader Wandile for pointing out the inconsistency.

    - Jonathan Ness, SRD blogger

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