Today we released six security bulletins addressing 19 CVE’s. Four of the bulletins have a maximum severity rating of Critical, one has a maximum severity rating of Important, and one has a maximum severity rating of Moderate. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

Today we released seven security bulletins addressing 20 CVEs (7 Microsoft and 13 Oracle CVE’s). Only one of the bulletins is rated Critical. The other six have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

In addition to the seven new security bulletins, we have re-released MS12-043 to make available a security update for Microsoft XML Core Services 4.0 on Windows 8. (MSXML4 does not ship with Windows by default but can be included as a redistributable component with installed applications.)

We are also revising security advisory 2661254 to note that the update is now available for all customers over Automatic Updates.

Finally, we are releasing a new security advisory, 2749655, describing potential compatibility issues due to incorrect digital certificate timestamps in recently-released security updates. You can read more detail about that situation in the security advisory and the SRD blog post.

Please let us know if you have any questions about this month’s release. You can email the MSRC Engineering research team at switech [at] microsoft [dot] com or tune in to the monthly webcast tomorrow at 11 a.m. PDT.  Click here to register for the webcast.

- Jonathan Ness, MSRC Engineering

Today we released Security Advisory 2749655 to alert customers to a clerical error made in code-signing a number of recently released security updates. This error will cause the digital signature to expire and become invalid prematurely – not a security flaw, but an issue that will impair users’ overall security profile. In this blog post, we’d like to provide more background on the mistake, explain the effect of this error on product functionality, and detail our response to the situation.

What happened?

All Microsoft security updates are code-signed by our Product Release and Security Services (PRSS) team. This central team also manages the code signing and release process for all production Microsoft software. Unfortunately, due to a clerical error, a subset of binaries processed by the PRSS lab between June 12, 2012 and August 14, 2012 were digitally signed in an incorrect manner.

The signing error involved the timestamp placed on each file as it was being signed. The certificate used for timestamping was missing a critical attribute that will cause the digital signature to become invalid at the point in the future when the package’s signing key has expired. Normally, the signing key is valid for a reasonably short amount of time, while the timestamp allows the binary to be trusted as “valid” for a much longer period of time.

Without a properly formed timestamp in place to extend the validity period, these binaries and packages will no longer be trusted as valid as soon as the signing key expires. For some of the affected files and packages, that signing key expiration date falls in the next few months.

Microsoft’s response to the situation

We will re-sign and redistribute all files and packages affected by this issue. Today, we are re-releasing an initial batch of four security updates -- MS12-053, MS12-054, MS12-055, and MS12-058 -- with new digital signatures, each of which has been timestamped with a proper timestamping certificate. We are continuing our investigation and expect to re-release additional bulletins as needed in months to come.

In addition to re-signing and re-distributing the affected files, we are taking an unusual approach to address this issue at the platform layer. The Windows team has created a package with a modified WinVerifyTrust function that makes a special case of the two known timestamping certificates that were missing the critical attribute. This will enable WinVerifyTrust to continue trusting these files and packages while redistribution completes. This WinVerifyTrust package is available as a Critical-class update and will be distributed over Microsoft Update and via Automatic Updates. It is also available on the Download Center directly at (link).

It is important to note that while WinVerifyTrust is the most common place where this check takes place, there are a number of known and potential points where trust may be verified by a third party (such as anti-malware software or software distribution solutions). If the vendor has not made a similar change to their trust model, these files or packages will fail validation. This is why we plan to re-sign and redistribute all files or packages affected by this issue. Again, the older versions of those files and packages are secure and trustworthy just as they are now, but may fail to be recognized as such in later months if they are not updated as soon as possible.

How WinVerifyTrust validates code signing signatures

To put this platform-level change into context (and for those who are not yet familiar with the validation process used by Microsoft products), we’d like to explain the three-step process that WinVerifyTrust uses to validate code-signing signatures. This process is merely a subset of the checks WinVerifyTrust performs, but it should make clear why Security Advisory 2749655 serves an important function.

First, it examines the signing certificate to confirm that it chains to a trusted root. In case of each of these packages, that trusted root is Microsoft. This first step of validation, then, ensures that you can trust that Microsoft signed each of these packages.

Next, WinVerifyTrust ensures that the signing certificate has not been revoked.

Finally, WinVerifyTrust checks that either (A) the certificate is in its validity period, or (B) that it has a timestamp that shows it was signed within its validity period. Because all files and packages signed during this period of time were signed with keys that are still within their validity period, they all pass trust verification. However, when these signing keys start to expire early next year, WinVerifyTrust will start examining the timestamp on these files and packages. With the updated WinVerifyTrust package available today to be downloaded, an option (C) has been added to satisfy this third step of validation. After passing the first two steps of validation, the third step can be satisfied by (A) a signing key still in its validity period, (B) a timestamp that shows it was signed within its validity period, or (C) one of these two specific known timestamping certificates that were missing the critical attribute.

Call to Action

We encourage all customers to apply the re-released, re-signed security updates as they become available.  As an additional defense-in-depth measure, we recommend that customers also apply the updated WinVerifyTrust package which serves as an effective way for Windows and Microsoft applications to extend the validity period of these packages beyond the premature expiration date.  We should be clear that the re-released, re-signed security updates by themselves are sufficient to address the potential compatibility issue and the WinVerifyTrust package is not strictly necessary - it is offered as a defense-in-depth option to customers who want to ensure that this issue does not affect them between now and the time they apply the updated security updates.

- Dustin Ingalls, Windows and Jonathan Ness, MSRC Engineering

Today, we revised Security Advisory 2757760 with two new pieces of information:

• A Fix It solution is available to address the vulnerability via an app-compat shim
• The comprehensive security update will be released out-of-band on Friday.

In this blog post, we’d like to explain more about the vulnerability and explain how the Fix It solution addresses the issue. We will also provide more details about the attack landscape and provide our assessment of the effectiveness of EMET against current attacks.

Information about the vulnerability

The vulnerability is a use-after-free issue that exists in the MSHTML module and affects versions 6, 7, 8, and 9 of Internet Explorer. Internet Explorer 10 is not affected. To trigger this type of memory corruption, the exploit invokes the method “execCommand()” to select the content of the web page while assigning a function handler to the event “onselect,” which will delete an object from the memory and try to dereference the freed object immediately after. The inconsistency generated in memory by this behavior may allow an attacker to take control of a function pointer in the VTABLE of the freed object and eventually execute arbitrary code.

Addressing the vulnerability via application compatibility shim

Today we released a Microsoft “Fix it” solution (an MSI package) as a new workaround option. It uses the Windows application compatibility toolkit to make a small change to MSHTML.DLL in memory every time the DLL is loaded by Internet Explorer. It addresses the use-after-free vulnerability by inserting the missing AddRef call within CMshtmlEd!Exec, similar to the actual code fix planned for Friday. You can read more about the Windows infrastructure that enables this type of workaround here: http://technet.microsoft.com/en-us/library/cc748912(WS.10).aspx

It’s important to note that the workaround will protect Internet Explorer only if the latest security updates have been applied. When the next security update affecting MSHTML is applied, the app-compat shim will be automatically deprecated and will no longer make in-memory changes. This is due to the surgical in-memory fix method targeting specific DLL versions. The .SDB file present in the MSI package that installs the app-compat shim database change has a list of DLL versions with specific offsets and assembly instructions for each version of the DLL.

To install the workaround, click here: http://go.microsoft.com/?linkid=9817706

If you’d like to uninstall the workaround after you have installed it, click here: http://go.microsoft.com/?linkid=9817705

Current attack landscape

We have analyzed the targeted attack samples that attempt to exploit this vulnerability. All real attacks we have seen are targeting only 32-bit versions of Internet Explorer and rely on third-party browser plugins to either perform efficient heap-spray in memory and/or to bypass the built-in mitigations of Windows Vista and 7 such as DEP and ASLR.  In the current situation, the chances of successful exploitation via the current attacks on Windows Vista and 7 strongly depend on the presence of these plugins on the targeted computers.  For example, all exploits relying on the presence of non-ASLR modules shipped by Java6 (as shown in the following code-snippet from a real exploit) can be mitigated by upgrading to the latest version of Java7, or by enforcing ASLR for these modules with EMET or by using the Force ASLR setting.

Using EMET mitigations

We also observed that the Enhanced Mitigation Experience Toolkit offers a good set of additional mitigations for Internet Explorer that can thwart many of the attacks in the wild. Enabling HeapSpray, MandatoryASLR and EAF mitigations for Internet Explorer will make reliable exploitation of this vulnerability more complicated. Users testing EMET 3.5 Tech Preview can use also the new set of mitigations able to break ROP-based exploits, which is also a recommended setting in the current situation.

If you encounter an attack sample for which you believe EMET is not an effective mitigation, please share it with us by emailing it to switech [at] microsoft [dot] com. We would love to take a look to improve the protections the tool offers to all customers.

Conclusion

We encourage you to make a risk decision for your environment and choose to either install the Fix It appcompat-shim based workaround or prepare to deploy the comprehensive security update when it is released on Friday. If you have already deployed EMET in your environment, ensure that the MandatoryASLR mitigation - at least - is enabled for Internet Explorer to raise the bar for attackers by blocking current exploits and introducing an additional cost factor in exploit development.

We will continue to monitor the situation and the evolution of exploit landscape.

Acknowledgements

Thanks to Elias Bachaalany, Cristian Craioveanu, Matt Miller and Suha Can for the hard-work which made possible delivering the Fix it workaround in such short time and for the endless work time spent to keep customers safe.

- Elia Florio, MSRC Engineering

MS-CHAP is the Microsoft version of the Challenge-Handshake Authentication Protocol and is described in RFC2759.  A recent presentation by Moxie Marlinspike [1] has revealed a breakthrough which reduces the security of MS-CHAPv2 to a single DES encryption (2^56) regardless of the password length.  Today, we published Security Advisory 2743314 with recommendations to mitigate the effects of this issue.

Any potential attack would require a man in the middle situation in which a third party can get all the traffic between the client and authenticator during the authentication.

Without going into much detail about the MS-CHAPv2 protocol, we will just discuss the part that would be affected by this type of attack: the challenge and response authentication.  This is how the client responds to the challenge sent by the authenticator:

• The authenticator sends a 16 byte challenge: CS
• The client generates a 16 byte challenge: CC
• The client hash the authenticator challenge, client challenge, username and create an 8 byte block: C
• The client uses the MD4 algorithm to hash the password: H
• The clients pad H with 5 null byte to obtain a block of 21 bytes and breaks it into 3 DES keys: K1,K2,K3.
• The client encrypts the block C with each one of K1,K2 and K3 to create the response: R.
• The client send back R,C and the username.

Or:

C=SHA1(CS,CC,UNAME)
P=MD4(PASSWORD)
K1|K2|K3=P|5 byte of 0
R=DES(K1,C)|DES(K2,C)|DES(K3,C)

There are several issues in this algorithm that combined together can result in the success of this type of attack.

First, all elements of the challenge and response beside the MD4 of the password are sent in clear over the wire or could be easily calculated from items that are sent over the wire. This means that for a man in the middle attacker, the gain of the password hash will be enough to re-authenticate.

Secondly, the key derivation is particularly weak. Padding with 5 bytes of zero means that the last DES key has only a key space of 2^16.

Lastly, the same plaintext is encrypted with K1 and K2, which means a single key search of 2^56 is enough to break both K1 and K2.

Once the attacker has K1, K2 and K3 he has the MD4 of the password which is enough to re-authenticate.

- Ali Rahbar, MSRC Engineering

[1]- https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/

Today we released MS12-060, addressing a potential remote code execution vulnerability in MSCOMCTL.OCX, the binary included with a number of Microsoft products to provide a set of common ActiveX controls.

Limited, targeted attacks exploiting CVE-2012-1856

MS12-060 is on the list of high priority updates for this month for two reasons: we are aware of very limited, targeted attacks taking advantage of CVE-2012-1856 and we expect to see new attacks taking advantage of this vulnerability in days ahead. We discovered this vulnerability in a malicious RTF file sent by email which attempted to run an exploit when opened with WordPad or Microsoft Word. Deploying MS12-060 will address the vulnerability and will protect against attacks. So once again we emphasize the urgency of applying this update as soon as possible.

Comparing MS12-060 to MS12-027 (previous MSCOMCTL bulletin)

MS12-060 addresses a different vulnerability than was addressed by the previous MSCOMCTL security update, MS12-027. The previous vulnerability (CVE-2012-0158) was a stack-based buffer overflow affecting both TreeView and ListView controls. MS12-060 instead fixes a different issue (CVE-2012-1856) caused by a wrong memory allocation present in the code of the TabStrip control. In both cases code execution is possible, but exploitation methods are very different. We expect to see attacks exploiting CVE-2012-1856 delivered as Office documents and mostly as RTF file due to the antivirus signature evasion options offered by RTF format that we previously observed watching the CVE-2012-0158 MSCOMCTL vulnerability.

Office mitigations against embedded controls

Microsoft Office includes various on-by-default mitigations and a range of optional security features that, added on top of MS12-060 security update, will offer additional protection layers against suspicious documents with embedded ActiveX controls (such as MSCOMCTL) or other potentially harmful active content. All these mitigations and additional protection settings have been covered and explained in details with a previous blog available at http://blogs.technet.com/b/srd/archive/2012/04/10/ms12-027-enhanced-protections-regarding-activex-controls-in-microsoft-office-documents.aspx. All the protection settings discussed in the previous blog, such as Office kill bit and Protected View, are valid defensive measures that will harden Office against similar attacks. The vulnerable CLSID for CVE-2012-1856 is 1EFB6596-857C-11D1-B16A-00C0F0283628.

One more additional protection layer that we found useful against RTF-based attacks is enabling by default the Protected View feature for all RTF files from the Office Trust Center panel. A simple setting that prevents automatic loading of embedded controls and active content in RTF documents. The Trust Center panel offers two possible configurations: opening RTF files in Protected View with or without editing features enabled. Opening the document in Protected View without editing will block attacks based on embedded controls while still allowing reading/viewing RTF documents. It is a very good safeguard against malicious RTF files with embedded controls.

Deploying EMET to mitigate the risk

Finally, we noticed that the Enhanced Mitigation Experience Toolkit (EMET) is able to mitigate or neutralize exploitation attempts for this vulnerability and so we encourage customers who want to add an additional layer of protection on top of the MS12-060 security update to consider deploying EMET at least to protect browser programs and Office applications on client machines. EMET 3.0 can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=29851.

Acknowledgement

Thanks to Ali Rahbar and Ali Pezeshk from MSRC Engineering for the help investigating this vulnerability.

- Elia Florio, MSRC Engineering

We released security update MS12-054 to address four privately reported issues in Windows networking components failing to properly handle malformed Remote Administration Protocol (RAP) responses. The most severe of these issues, CVE-2012-1851, is a format string vulnerability in the printer spooler service while handling a response message and is a wormable-class vulnerability on Windows XP and Windows Server 2003. At least, sort of wormable. This blog post will explain the attack scenario and the limited affected platforms to help you assess the risk this vulnerability poses to your environment.

What is the RAP protocol?

Windows workgroups and domains maintain a lookup list of network resources such as printers, SQL servers, and file servers. Each time a new resource becomes available (such as a new printer being shared or a SQL Server booting up), the server hosting the resource notifies the subnet’s master browser (or backup browser). Any application or workstation that needs a specific type of resource can then query its subnet’s master browser or backup browser to respond with a list of resources of the requested type. The MSDN NetServerEnum documentation explains how an application can query the subnet browser for network resources and the type of resources available to be queried. Amongst other uses, the Remote Administration Protocol (RAP) is the protocol included with Windows to perform these types of administrative functions. 

Potential Attack Scenario

All four vulnerabilities addressed by MS12-054 are client-side parsing issues of malformed RAP responses. To trigger the vulnerability by sending a malicious response, an attacker would need to either act as a subnet’s browser or populate the legitimate master/backup browser’s lookup table with malformed records which would be relayed to clients when they request a resource of a certain type. Windows XP users face the most significant risk from these vulnerabilities, as indicated in the affected products chart at the end of this blog post. A commonly exercised user experience path that initiates a NetServerEnum call (and subsequent RAP request) is the Windows XP “View workgroup computers” link in the “My Network Places” dialog box, shown below:

How is this “wormable”?

In addition to the "My Network Places" user-initiated scenario above, several "on-by-default" scenarios also exist on Windows XP.  For example, winlogon initiates a request using this protocol to find domain controllers.  The client-side group policy component also initiates RAP requests to which a malicious subnet browser could return a malformed attack response.  CVE-2012-1851, as an example, involves the print spooler service on Windows XP and Windows Server 2003, a service that regularly polls/queries the subnet browser for a list of shared printers.  It would be "wormable" given the following conditions:

• Victim workstations running Windows XP or Windows Server 2003
• Attacker is capable of being elected master browser on the victim’s subnet
    OR
  Attacker is able to populate the real master browser’s printer list with a malformed record
    AND
  Print Browsing group policy option is enabled on the real master browser.
• Workstation Service (LanMan) running on victim workstation.
• Printer spooler service running on victim workstation.

Every two minutes, the victim’s print spooler service will call the NetServerEnum API to enumerate shared, available printers. This instructs the Workstation service to initiate a RAP request over SMB to the subnet's browser. The subnet browser could then potentially send back a malformed response which would be passed to the spooler service, triggering the vulnerability. The chart below describes the flow.

Affected Platforms

The affected platforms list is full of good news for customers that have migrated to newer versions of Windows. First, two of the vulnerabilities (CVE-2012-1852 and CVE-2012-1853) affect only Windows XP. The vulnerability affecting the Browser service (CVE-2012-1850) is rated Moderate on Vista and later platforms because the Browser service is off by default starting with Windows Vista. And, finally, the print spooler service code execution vulnerability (CVE-2012-1851) manifests only as a denial-of-service on Windows Vista and does not affect later platforms at all in their default configuration.

The table below summarizes the risk per platform:

We hope this information helps you assess the risk of this “sort of wormable” issue in your environment. Please let us know if you have any questions.

- Jonathan Ness, Neil Sikka, and Gangadhara Swamy, MSRC Engineering

Today we released nine security bulletins addressing 26 CVE’s (13 Microsoft and 13 Oracle CVE’s). Five of the bulletins have a maximum severity rating of Critical and the other four have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

In addition to the nine new security bulletins, we have re-released MS12-043 to make available a security update for Microsoft XML Core Services 5.0 that was unavailable at the time of initial release.

Finally, we have also released a new security advisory, KB 2661254, to inform customers of an update available on the Download Center that restricts the use of certificates with RSA keys less than 1024 bits in length. This advisory announces that we plan to release this update through Microsoft Update in October, 2012 after customers have a chance to evaluate their unique environments with the update and take necessary actions to use certificates of 1024 or greater bit length.

- Jonathan Ness, MSRC Engineering

Now that we have announced the winners of the first BlueHat Prize competition, we wanted to provide some technical details on the top entries and explain how we evaluated their submissions. Speaking on behalf of the judges, it was great to see people thinking creatively about defensive solutions to important security problems!

To set the stage for this post, we thought it would be helpful to quickly remind everyone of the problem that entrants needed to solve.  Specifically, entrants were required to design a novel runtime mitigation technology that would be capable of preventing the exploitation of memory safety vulnerabilities (such as buffer overruns).  The BlueHat Prize judging panel was then responsible for evaluating each submission as described according to the following criteria (as described in the contest rules):

1. Practical and functional (30%)
1. Can the solution be deployed at large scale?
2. Does the prototype have low overhead?
3. Is the prototype free of any application compatibility or usability regressions?
4. Does the prototype function as intended?
2. Robustness (30%)
1. How easy would it be to bypass the proposed solution?
3. Impact (40%)
1. Does the solution strongly address key open problems or significantly refine an existing approach?
2. Would the solution strongly mitigate exploits above and beyond Microsoft’s current arsenal?

The judges for this contest consisted of representatives from Windows, Microsoft Research, and Microsoft’s Security Engineering Center (MSEC).  Of the 20 entries received, the top three submissions described different methods of mitigating return oriented programming (ROP).  Let’s dive into the technical details of these submissions.

3^rd place: mitigating ROP via return site whitelisting (/ROP)

This entry, as submitted by Jared DeMott, described a method of imposing a whitelist on the set of locations that a return instruction can transfer control to.  More specifically, this solution calls for the introduction of a new compiler flag (“/ROP”) that would add metadata to an executable that describes the set of valid return sites in the image.  When the image is loaded at runtime by the operating system, the image’s list is added to a master list.  As the program executes, each invocation of a return instruction triggers an exception that causes the operating system to validate the target return site against the master list of return sites.  If the target return site is in the list, the program continues executing as normal; otherwise, the program is safely terminated. 

To prototype this idea, the submission included a Pin tool that simulated the hardware support that would be needed to augment the behavior of the return instruction.  In addition, the prototype also included an IDA Python script to identify the set of valid return sites for an image.  This script generated the input that was needed for the Pin tool to check whether a return target was to be considered valid.

Practical and functional

Although this solution is functional, it is not seen as practical for large scale deployment as described. The primary reason for this is due to the execution cost associated with implementing this check. This cost is expected to be significant because the design calls for a software interrupt to be raised for each return instruction.  A second issue with this design is related to the data structure that is used to store the address of valid return sites.  In particular, the prototype of this design uses the STL map container which, although it enables O(1) lookups, is not optimally compact and can therefore lead to considerable memory overhead depending on the number valid return sites that exist in modules loaded by a process.  The design for this solution did not propose optimizations that could help to address both of these concerns.

Robustness

This solution is seen as a partial mitigation for ROP.  It could be bypassed by leveraging gadgets that are in the set of valid return sites or by using a gadget chaining method that does not involve a return instruction.  The feasibility of finding a sufficient set of gadgets in the set of valid return sites is expected to be uncommon.  The use of alternative chaining methods is feasible, although the complexity associated with doing so exceeds the current state of the art in ROP-based exploits seen in the wild.

Impact

This solution would have a moderate impact if were possible to deploy it at large scale.  The fact that this solution does not fully address all forms of code re-use limits the expected long term impact of the design as described.

2^nd place: mitigating ROP by placing new checks in critical functions (ROPGuard)

This entry, as submitted by Ivan Fractic, described a method of mitigating ROP by introducing additional checks that are performed when critical functions, such as VirtualProtect, are called.  These checks are designed to detect conditions that are indicative of ROP occurring, such as an API being called out of context.  The checks proposed by this submission included:

1. Verifying that the stack pointer is within the bounds of the thread’s stack.
2. Verifying that that the return address of a critical function is executable and preceded by a call.
3. Verifying that all stack frames are valid and satisfy criteria 1 and 2.
4. Simulate execution forward from a critical function’s return address to verify that subsequent returns satisfy criteria #2.
5. Function specific contract changes (e.g. prevent reprotecting of the stack as executable).

Although adding checks to critical functions to detect ROP is not a new idea, and indeed some of the checks above have already been described in previous research, this submission included novel elements that we had not seen discussed before.  We actually received a number of submissions which proposed adding new checks to critical functions, but the other submissions had a subset of the checks proposed by this submission or by previous research.

Practical and functional

The checks proposed by this submission are considered to be both practical and functional.  By limiting these checks to certain critical functions, the performance impact is minimized.  Some of the proposed checks would be incompatible with certain applications.  Specifically, criteria #1 is known to be incompatible with some legacy applications that do custom stack switching and #3 is incompatible with x86 programs that enable frame pointer omission.

Robustness

ROP mitigations that rely on introducing new checks to critical functions are not considered to be robust over the long term.  The checks proposed by this submission and in previous research are capable of mitigating ROP payloads that are used today, but it is expected that attackers would be able to adapt to these checks at relatively low cost.  For example, a fundamental problem with this type of approach is that an attacker could attempt to call a lower level API that has not been instrumented by the checks.  A variant of this bypass is to transfer control after the instruction block that performs the checks (depending on how the checks have been added).

Impact

This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described.

1^st place: mitigating ROP via Last Branch Recording (kBouncer)

This entry, as submitted by Vasilis Pappas, described a novel method of using the Last Branch Recording (LBR) feature of Intel processors to detect ROP when system calls are made.  This method relies on a kernel component that allows branch recording to be enabled for return control transfers.  When a system call occurs, the kernel component then enumerates each entry in the LBR stack and verifies that the destination address is preceded by a call instruction.  The prototype for this solution relied on evaluating the contents of the LBR when certain critical APIs were called rather than at the system call layer.  The cited reason for this was due to Windows kernel restrictions around interposing the system call layer in kernel mode.

Practical and functional

This solution is considered to be both practical and functional.  The use of supported hardware features to track the destination address of return control transfers helps to drive down the performance cost and complexity of implementing this solution.   There should also be minimal application compatibility impact through this approach.

Robustness

This solution is not expected to be robust over the long term, although it should be robust against ROP payloads that are used today.  There are multiple reasons why it is not expected to be robust.  First and foremost, the Last Branch Recording feature of Intel processors has a limited stack for storing control transfers (16 entries on Nahelam and up).  If an attacker can ensure that a sufficient number of valid returns happen between the control transfer that eventually leads to an API call and the point where the LBR stack is checked, then this solution can be bypassed.  It is believed that attackers would be able to accomplish this in most cases with a low to moderate development cost.  While it may be possible to use the Branch Trace Store (BTS) feature to help address this problem, the performance cost may become unacceptable.  The other reasons for this solution not being robust are shared with the two previous submissions: specifically, imposing these checks on specific APIs (as in the prototype) may be prone to bypasses and imposing checks only on returns does not mitigate all methods of chaining gadgets.

Impact

This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described.

Closing thoughts

The winning submissions illustrate some of the creative thinking that has gone into developing defensive methods of making it more difficult and costly to exploit memory safety vulnerabilities.  As we look toward the future, we will investigate whether there are elements of these methods that may make sense to integrate into EMET or a future version of our products.  We have already taken steps in this direction by integrating features from the ROPGuard submission and related prior research into the Technical Preview of EMET 3.5.

As the judging criteria makes it clear, it can be quite challenging to turn an interesting defensive security idea into something that can be shipped in a retail product at large scale.  Nevertheless, ideas that may seem impractical on the surface can eventually be turned into an innovative and practical solution – it just takes some additional focused thinking.

Matt Miller

MSEC Security Science

Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a number of tools capable of mitigating selected web specific vulnerabilities (for example, UrlScan). To help on this front we have participated in a community effort to bring the popular open source module ModSecurity to the IIS platform. Yesterday at Black Hat Las Vegas, we have announced the availability of an RC version and we expect that stable release will be available soon.

Installation

Although the source code of ModSecurity’s IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in SourceForge repository), it is highly not recommended to self-build the module for non-research or non-development purpose.

A standard MSI installer of ModSecurity for IIS 7 and later versions is available from SourceForge files repository of ModSecurity project and in the future designated maintainers will be keeping it updated with latest patches and minor versions of the module.

Configuration

The IIS installer does not interfere with currently running web applications. This means that the installation process must be followed by an application pool restart or recycling in order to load the new module into the application pool process. For the RC version of the module the restart/recycle step is also highly recommended each time a ModSecurity configuration file has been changed:

After successful load of the module into the application pool process a series of informational events is recorded in the application event log:

Runtime messages and notifications generated during the operational phase, both coming from the user-defined rules and system specific events or errors, are sent to the same application event log repository.

To apply a ModSecurity configuration file to a web application or a path, one has to use IIS configuration schema extension, like in the example below:

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\test.conf" />

    </system.webServer>

</configuration>

The c:\inetpub\wwwroot\test.conf config file is a regular ModSecurity configuration containing the same directives as used on the Apache web server.

Examples of Protection

The most common application of ModSecurity is a protection layer called “virtual patching” (see Resources section, [5]). Using two recent vulnerabilities as an example we would like to show how this layer can be specified in an environment with IIS server running with ModSecurity.

CVE-2011-3414

In December 2011 a vulnerability was addressed in ASP.NET that allowed attackers to cause excessive processor load on most ASP.NET web applications. The hash collision issue required attacker to send a large (typically 1MB or 4MB) POST request to the server, with tens of thousands of arguments with specially crafted names. There are at least four ways to mitigate this kind of attack:

• Restrict the request body size.
• Restrict the number of arguments.
• Identify repetitive payloads.
• Check arguments names against PoC data.

The approach of checking for the presence of repetitive payload is the most sophisticated one and it can be implemented in ModSecurity using the following chain of rules:

SecRule &ARGS "@ge 1000" "chain,id:1234,phase:2,t:none,deny,msg:'Possible Hash DoS Attack Identified.',tag:'http://blogs.technet.com/b/srd/archive/2011/12/27/more‑information‑about‑the‑december‑2011‑asp‑net‑vulnerability.aspx?Redirected=true'"

  SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&" "chain,capture"

    SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1"

    SecRule TX:2 "@streq %{tx.3}" "chain,setvar:tx.hash_dos_match=+1"

    SecRule TX:3 "@streq %{tx.4}" "chain,setvar:tx.hash_dos_match=+1"

      SecRule TX:HASH_DOS_MATCH "@eq 3"

When this rule is loaded into an IIS server configuration and the attack is launched on the protected path, the Windows application event log will record an access denied message from ModSecurity:

At the same time the attacker will see HTTP response 403, stopping the attack before it reaches ASP.NET vulnerable component.

CVE-2012-1859

In July 2012, Microsoft patched a classic case of reflected cross-site scripting vulnerability in Microsoft SharePoint 2010. For the attacks to exploit the vulnerability it was enough to trick user into clicking on a malicious URL, like the one below:

http://sharepoint/_layouts/scriptresx.ashx?culture=en‑us&name=SP.JSGrid.Res&rev=laygpE0lqaosnkB4iqx6mA%3D%3D&sections=All<script>alert(‘Hacked!!!’)</script>z

The script injected by the attacker could gain access to the entire data set available to the victim through the hacked SharePoint server.

One possible way to block this attack is a whitelist approach: let the URL with sections argument that does contain only valid characters pass through, while block all other URLs. Below is a ModSecurity rule implementing this approach for alphanumeric characters:

SecRule REQUEST_FILENAME "@contains /_layouts/scriptresx.ashx" "chain,phase:1,block,msg:'SharePoint Sections Param Violation - Illegal Chars"

  SecRule ARGS:sections "!@rx ^\w+$"

The rule included through ModSecurity config file into the SharePoint web.config file, generates the following event when any invalid character (indicating possible attack attempt) is discovered in the corresponding SharePoint URL:

Feedback

We encourage you to download and try out the tool.  If you have any feedback on your experiences with the tool, you can reach us at switech@microsoft.com.

Acknowledgments

The following people have contributed to the multi-platform effort of ModSecurity:

•  Microsoft – ModSecurity Port for IIS
  •    Greg Wroblewski – Senior Security Developer
  •    Suha Can – Security Researcher / Developer
•  Trustwave - ModSecurity
  •    Ziv Mador – Director of Security Research
  •    Ryan Barnett – Security Researcher Lead
  •    Breno Pinto – ModSecurity Researcher & Developer
•  Open community  - Security Port for Nginx
  •    Alan Silva  - Software Engineer at Locaweb

We would like to thank Wade Hilmo and Nazim Lala, members of the Microsoft’s IIS team, for their support and help in solving many technical problems.  Finally, thanks to Russ McRee for the behind-the-scenes collaboration and encouragement which kicked off this effort.

Resources

[1]    ModSecurity home page: http://www.modsecurity.org/

[2]    OWASP Core Rule Set for ModSecurity: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[3]    http://blog.modsecurity.org/files/enough_with_default_allow_r1_draft.pdf

[4]    http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf

[5]    https://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf

[6]    http://holisticinfosec.blogspot.com/2012/12/toolsmith-modsecurity-for-iis.html

-          Greg Wroblewski, Microsoft Security Engineering Center

-          Ryan Barnett, Trustwave