Today we are shipping a security update to address a Critical-class memory corruption vulnerability in the Microsoft C Run-Time Library (msvcrt.dll) shipped with Windows. We have issued the bulletin with Critical severity because attackers could potentially trigger the vulnerability by luring a victim into browsing to a malicious webpage that launches Windows Media Player, or by opening a malicious file with Windows Media Player.

Seldom-used functionality

While the Windows Media Player attack vector is unfortunate, one might look at the affected DLL (msvcrt.dll), recognize that a number of Microsoft applications load the DLL, and speculate that a large percentage of applications might be vulnerable. Thankfully, that is not the case. Based on what we have seen in our code base, the affected functions are rarely used by components shipping with Windows. At this time, Media Player is the only known vector to provide an exploit path for the vulnerability. And even if other attack vectors are discovered, after applying the security update, all Microsoft products will be protected from the issue.

Applications built with recent versions of Visual Studio are safe by default

All applications built with Visual Studio 2003 and higher are not affected by this issue, unless they are specifically loading msvcrt.dll. Starting from Visual Studio 2003, any program that is dynamically linked to the C Run-Time library will use msvcrXX.dll instead of msvcrt.dll.

It is important to note that msvcrt.dll is a known DLL. This means that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcrXX.dll. Windows will only look in %WINDIR%\system32 to locate msvcrt.dll. Any application that is linked to msvcrt.dll will load the vulnerable version, regardless of the presence of another version in the current directory – though, again, applying this bulletin eliminates the issue.

Guidance for 3rd party application developers

If you have developed an application by statically linking to the C Run-Time library shipped with Visual Studio, you are safe. If your program is dynamically linked to the C Run-Time library, then you should ensure that all your objects are linked with a recent version of Visual Studio. This will assure that you are using msvcrtXX.dll and are not affected by this problem.

- Ali Rahbar, MSRC Engineering

Today, we shipped security update MS12-014 to address an issue in the Indeo codec. With this blog post, we hope to preemptively answer some common questions that are likely to surface as researchers analyze this security update.

Indeo: Blast from the Past

Indeo is a video codec that was first developed in 1992, long before some of you reading this blog post were born. :) In the days before MPEG – and more than a decade before youtube – Indeo was one of the first video codecs allowing full-speed video playback without using hardware acceleration.

However, today Indeo is an obsolete technology. In fact, Windows Vista and all later versions of Windows shipped with the codec disabled by default. In 2009, we took a further step of attack surface reduction for older versions of Windows by releasing a security advisory and shipping an update to block Indeo from being launched in Internet Explorer or Windows Media Player. That update, shipped via Automatic Updates, removed the most common remote attack vectors for this code while still allowing games or other legacy applications to leverage the codec locally and continue to function.

MS12-014: Why and How

Windows now blocks the remote video playback functionality of Indeo but the codec itself and its infrastructure remain on the system for legacy application support. Unfortunately, a DLL Preloading issue has been identified leveraging Indeo. In the following set of circumstance, an attacker could run arbitrary code on a system:

• If an attacker lures a victim into browsing to a network share or WebDAV share where attacker has write access, AND
• If the attacker lures victim into double-clicking a content filetype that is handled by or registered to Indeo, AND
• If the attacker has placed a specifically-named malicious DLL on the share,
• Then Indeo will inadvertently load the malicious DLL while attempting to open the content file on which the victim double-clicked.

Due to the particular challenges in servicing Indeo, we took an unusual approach this time. This security update drops a “dummy DLL” on the system having the filename that the attacker’s malicious DLL would need to have to exploit the vulnerability. This effectively removes the vulnerability because the DLL will be found already on the system and Indeo will not attempt to load a malicious DLL from the attacker-controlled share.

Hope that helps answer questions you might have about this security update.

Thanks to Josh Carlson, MSRC Ops for the help with this one. (and congrats on shipping your first bulletin)

- Jonathan Ness, MSRC Engineering

Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.

CVE-2012-0003

The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.

An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.

Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\CLSID\{D51BD5A2-7548-11CF-A520-0080C77EF58A}]

CVE-2012-0004

CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.

As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.

Summary

MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.

Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.

- Chengyun Chu, MSRC Engineering

Today we released MS12-001, which addresses an issue that can enable an attacker to bypass a defense in depth feature known as SafeSEH. This bypass is limited in scope to applications that make use of binaries that were built with Microsoft Visual C++ .NET 2003 RTM. Binaries that have been built with Microsoft Visual C++ .NET 2003 Service Pack 1 and beyond are not affected. In this blog post we wanted to provide more details on the issue that has been addressed and what impact it has. In addition, we’ll clarify the parameters of the “Security Feature Bypass” vulnerability category assigned to this bulletin.

What is SafeSEH?

SafeSEH is a defense–in-depth security feature that is designed to make it more difficult for attackers to exploit certain types of vulnerabilities. In particular, SafeSEH is designed to prevent attackers from using an attack technique known as an “SEH overwrite”. More details on how this is accomplished can be found in a report we released in July of last year: http://go.microsoft.com/?linkid=9776900.

Microsoft released support for SafeSEH in Visual Studio 2003 RTM. Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 were the first versions of Windows to be built with SafeSEH enabled.

What issue is being addressed?

This issue can result in SafeSEH not being enforced for a binary that has been built with support for SafeSEH. This occurs when a binary that was built with Microsoft Visual C++ .NET 2003 RTM is loaded by an application running on a version of Windows that is affected by MS12-001.

The reason that SafeSEH is not enforced in this scenario is because Microsoft Visual C++ .NET 2003 RTM produces binaries with metadata that is a different size than what the Windows loader expects. As a result, the loader conservatively falls back to assuming that the binary does not support SafeSEH. MS12-001 addresses this issue by allowing binaries to have metadata of the size that is produced by Microsoft Visual C++ .NET 2003 RTM.

What impact does this issue have?

Failing to enforce SafeSEH for a binary can enable an attacker to more easily develop an exploit for a vulnerability. The attacker must have found a vulnerability that can enable code execution for this to be possible; the issue addressed by MS12-001 does not enable code execution in and of itself. Furthermore, it does not enable elevation of privilege, information disclosure, or the like. For this reason, we’ve assigned MS12-001 to the very small category of “Security Feature Bypass” vulnerabilities. Though failure to enforce SafeSEH is by no means desirable, the issue in itself does not constitute an exploit vector.

Although the set of binaries affected by this issue is limited, some of the affected binaries are extensively used by applications. For example, the redistributable C runtime DLLs (such as msvcrt.dll) from Visual Studio 2003 are affected by this issue. These DLLs also do not enable support for ASLR and are therefore an attractive target for use in developing an exploit. EMET can be used to better mitigate these concerns by enabling mandatory ASLR and SEHOP for applications that make use of such DLLs.

Do I need to rebuild my binaries if they were built with Visual C++ 2003?

Installing the update for MS12-001 will fully address this issue without requiring any binaries to be rebuilt. Alternatively, this issue can also be resolved by rebuilding affected binaries with Microsoft Visual C++ .NET 2003 Service Pack 1 or later. You can determine if your binary is affected by this issue by using the Microsoft Visual C++ linker command “link.exe /dump /headers binary.dll”. Binaries with a Load Config Directory size of 0x48 are affected as shown below.

File Type: DLL
7.10 linker version
…
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
3AC74 [    43E0] RVA [size] of Export Directory
49298 [      28] RVA [size] of Import Directory
52000 [     3B8] RVA [size] of Resource Directory
0 [       0] RVA [size] of Exception Directory
0 [       0] RVA [size] of Certificates Directory
53000 [    2B64] RVA [size] of Base Relocation Directory
39B48 [      38] RVA [size] of Debug Directory
0 [       0] RVA [size] of Architecture Directory
0 [       0] RVA [size] of Global Pointer Directory
0 [       0] RVA [size] of Thread Storage Directory
49078 [ 48] RVA [size] of Load Configuration Directory

Thanks to Gerardo Di Giacomo and our colleagues in Windows Sustained Engineering for their work on addressing this issue.

Matt Miller, MSEC Security Science

Today we released seven security bulletins. One has a maximum severity rating of Critical with the other six having a maximum severity rating of Important. 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 MS11-100, addressing a newly disclosed denial-of-service vulnerability affecting several vendors’ Web application platforms, including Microsoft’s ASP.NET. Yesterday, we posted an SRD blog describing the vulnerability and the detection and workaround opportunities. With this blog post, we’d like to update you on the following topics:

• Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?
• Signature progress from protection partners
• Updated snort rules
• Thanks to the ASP.NET team for holiday heroics

Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?

Yesterday evening, we published an Advanced Notification alerting customers to a new out-of-band security update planned to be released today. The notification listed the update as addressing a Critical Elevation-of-Privilege vulnerability, leading to several questions from customers who expected the bulletin addressing a Denial-of-Service vulnerability to be rated Important.

Before hearing about this vulnerability, we had planned to release a .NET security update addressing three vulnerabilities, one of which was a Critical elevation-of-privilege vulnerability. When this vulnerability notification arrived a few weeks ago, the ASP.NET team included the fix into the update already being developed and tested. So the bulletin today addresses four vulnerabilities, one of which is the ASP.NET Denial-of-Service vulnerability presented yesterday. You can read more about the other vulnerabilities in the Security Bulletin and we also invite you to join us for a webcast at 1:00 p.m. PST today (Dec 29) where we will describe the vulnerabilities and answer your questions live “on the air.” You can sign up for the webcast here.

Signature progress from protection partners

We have been working with our MAPP partners, answering questions and providing additional guidance. We are seeing early progress toward signatures, one of which being our own MMPC team having released a signature for the Forefront Threat Management gateway (TMG). The MMPC signature page is at http://www.microsoft.com/security/portal/Threat/Encyclopedia/NIS.aspx?threat=Vulnerability-Win-ASPNET-POST-DoS-CVE-2011-3414. We have also heard from partners about the progress they are making and are looking forwarding to seeing additional signatures this week. It’s exciting to see this information sharing mechanism working!

As we mentioned earlier, Web application servers from several vendors are affected by this same vulnerability. The “nice” thing about these kind of industry-wide issues is that our detection logic sent out to the MAPP partners results in protection for not just the Microsoft issue but for attacks targeting any affected platform.

Updated Snort rules

Sourcefire, while developing their IDS/IPS signature, has been kind enough to share their Snort rule with us and has given us permission both to use it in protecting Microsoft’s properties and also to share with customers. While the Snort rules we provided in the blog yesterday were effective in detecting the issue, Sourcefire's rules are more efficient. The first signature from yesterday would operate very rapidly, but the second – which had no static content match – would enter on every single TCP packet passing through the IDS. While it would exit rapidly in most cases due to the flowbit, the overhead from that would stack up and if the PCRE runs into a form post that sends 20+ parameters, the PCRE would start crunching away on the CPU quite rapidly. Thanks, Sourcefire team, for your help!

To that extent, here are two updated Snort rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| application|2F|x-www-form-urlencoded"; nocase; http_header; pcre:"/([^=]+=[^&]*&){500}/OP"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20823; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| multipart/form-data"; nocase; http_header; pcre:"/(\r\nContent-Disposition\x3a\s+form-data\x3b[^\r\n]+\r\n\r\n.+?){500}/OPsmi"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20824; rev:1;)

This first rule covers the x-www-form-urlencoded use case in a single rule, instead of using flowbits, because the stream reassembler and http_inspect will put the entire request together, and allows you to view it as a single logical packet. That eliminates the concern about a rule without a content match, and means that it should be reasonably fast. Also, this changes the number of parameters necessary to trigger an alert down to 500, because a) that should have virtually no false positives in the wild anyway, and b) the fewer parameters the PCRE needs to count out, the faster the rule will be. The second rule covers the multipart/form-data use case.

Additional acknowledgement

The ASP.NET team has worked straight through the past several weeks to make this short turnaround release possible – building, packaging, and testing this security update in order to release packages in such a short time so we could protect customers as quickly as possible.

Yesterday’s SRD blog mentioned a few of the team members but missed several others. With apologies to the team members who didn’t get mentioned and at the risk of forgetting others, here are the key ASP.NET engineers who made this compressed schedule possible: Anand Paranjape, Pranav Rastogi, Jim Wang, Clay Compton, Matt Fei, Hong Li, Carl Dacosta, Amit Apple, Drago Draganov, Konst Khurin, Levi Broderick, Miguel Lacouture-Amaya, Jason Pang, Jim Carley, Jon Cole, Mike Harder, Zhenlan Wang, Dmitry Robsman, Jeffrey Cooperstein, Nazim Lala, Qing Ye, Reid Borsuk, Jamshed Damkewala, Christy Henriksson, Jose Reyes, William Mitchell, Darla Hershberger, Sophy Wang, and Ashutosh Kumar. Thanks, all of you and others behind the scenes for your work to get this package out in such a short time!

Dec 29 update:  Updated Snort rule with more efficient pcre from Sourcefire team.  Previously "/([\w\x25]+=[\w\x25]*&){500}/OPsmi".  Now "/([^=]+=[^&]*&){500}/OP".  Should be ~10x faster.  Thanks Caleb Jaren from the Microsoft Network Security Analysis & Monitoring team for testing it.

- Jonathan Ness, MSRC Engineering

Today, we released Security Advisory 2659883 alerting customers to a newly disclosed denial-of-service vulnerability affecting several vendors’ web application platforms, including Microsoft’s ASP.NET. This blog post will cover the following:

• Impact of the vulnerability
• How to know if your configuration is vulnerable to denial-of-service
• How to detect the vulnerability being exploited at network layer
• How to detect the vulnerability being exploited on the server
• Background on the workaround to protect your website

Impact of the vulnerability

This vulnerability could allow an anonymous attacker to efficiently consume all CPU resources on a web server, or even on a cluster of web servers. For ASP.NET in particular, a single specially crafted ~100kb HTTP request can consume 100% of one CPU core for between 90 – 110 seconds. An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even multi-core servers or clusters of servers.

We anticipate the imminent public release of exploit code. Therefore, we encourage ASP.NET website owners to review the Security Advisory 2659883 and this blog post to evaluate the denial-of-service risk to your web property and to implement the workaround and/or attack detection mechanisms until a security update is available to comprehensively address the issue.

Vulnerable configurations

The root cause of the vulnerability is a computationally expensive hash table insertion mechanism triggered by an HTTP request containing thousands and thousands of form values. Therefore, any ASP.NET website that accepts requests having HTTP content types application/x-www-form-urlencoded or multipart/form-data are likely to be vulnerable. This includes the default configuration of IIS when ASP.NET is enabled and also the majority of real-world ASP.NET websites.

Detecting attacks at the network layer

Microsoft has released detailed detection guidance and code to test signatures to all 80 of our MAPP partners. We expect that the network-based IDS and IPS vendors in the program will build robust detection and protection signatures for this issue. Microsoft’s own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability:Win/ASPNET.POST.DoS!NIS-2011-0001)

Microsoft’s internal network security analysis & monitoring team has developed a snort signature to detect attacks on the wire. They are currently testing it and plan to put it into production to protect Microsoft’s own network. There are two rules:

alert tcp any any -> any $HTTP_PORTS (msg:"Microsoft 2659883 URL Encoded Content flowbit"; flow:established,to_server; content:" application|2F|x|2D|www|2D|form|2D|urlencoded";nocase;http_header;flowbits:set,urlEncodedContentType;flowbits:noalert;classtype:misc-activity; sid:1000019; rev:1;)

alert tcp any any -> any $HTTP_PORTS (msg:"Confirmed Microsoft 2659883 payload";flow:established,to_server;flowbits:isset,urlEncodedContentType;pcre:"/(\w*(&|=)){1000,}/smi";flowbits:unset,urlEncodedContentType; sid:1000020;rev:1;)

The first rule will check for the content type “application/x-www-form-urlencoded”. If it is present, the rule will set the flowbit “urlEncodedType”. If the urlEncodedType flowbit is set, the second rule will check for 1000 or more form values being sent in the HTTP request. As Microsoft, the other affected vendors, and protection partners continue to investigate this issue, we will likely discover more efficient ways to detect exploits in the wild. Please contact us at switech –at- microsoft dot com with ideas for more efficient detection than the above.

Detecting attacks at the server level

Successful attacks will exhaust server CPU resources. Therefore, you can detect attacks by something as simple as Task Manager on the web server. The screenshot below shows the result of one malicious request against a 4 core machine. Notice that one entire core is dedicated to processing this one request (~25% CPU usage).

More information about the workaround to protect your web properties

The security advisory lists workaround steps to limit the maximum HTTP request size that ASP.NET will accept from clients. Attackers would need to send (relatively) large HTTP requests to exploit the vulnerability. So if your website does not normally need to accept large requests from legitimate users, you can configure ASP.NET to reject all requests larger than a certain size. Note that if your website does need to accept user uploads, this workaround is likely to block legitimate requests. In that case, you should not use this workaround and instead wait for the comprehensive security update.

If your application uses ViewState, we recommend limiting HTTP request size to 200kb. To do so, add the following to your ASP.NET configuration file:

<configuration>
 <system.web>
 <httpRuntime maxRequestLength="200"/>
 </system.web>
</configuration>

If your application does not use ASP.NET ViewState, we recommend limiting HTTP request size to 20kb.  To do so, add the following to your ASP.NET configuration file:

<configuration>
 <system.web>
 <httpRuntime maxRequestLength="20"/>
 </system.web>
</configuration>

Note that any requests larger than the maxRequestLength will result in a ConfigurationErrorsException thrown server-side and an HTTP error status returned to the client. Therefore, we want to stress that this workaround option will disrupt both legitimate and attack HTTP requests that exceed the request length. Therefore, please thoroughly test this workaround in your environment, focusing on any scenarios that involve uploading files or making large data submissions to the web service.

Non-workaround – URLScan

Microsoft’s URLScan tool often helps mitigate vulnerabilities involving malicious HTTP requests. However, it is not applicable in this particular case because the malicious form values in a successful attack are most likely to be in the body of the HTTP request, not in the URL itself. URLScan does not inspect the request body. Attacks are unlikely to be successful using only the URL (even factoring in cookies, headers, server variables, etc) due to a default 16KB limit for the combined request size excluding the request body. The request body is the only unbounded payload.

Conclusion

Our ASP.NET team is hard at work testing a security update for broad deployment. If you are concerned about the risk of your ASP.NET site being targeted by attackers, please consider implementing the detection and workaround guidance described in this blog post.

Thanks to the ASP.NET team for the hours and hours of work spent over the holiday on this issue - Dmitry Robsman, Jeffrey Cooperstein, Zhenlan Wang, Matt Fei, Nazim Lala, Jamshed Damkewala, Hong Li, Reid Borsuk and others! Thanks Mike Harder for your work investigating different workaround options. Thanks Dave Midturi, David Seidman, Andrew Gross, and Maarten van Horenbeeck for your help in coordination. Thanks Chengyun Chu and Ali Pezeshk for your technical investigation. And finally thanks Caleb Jaren and Abhijeet Hatekar for the snort signature help!

- Suha Can and Jonathan Ness, MSRC Engineering

Today we released thirteen security bulletins. Three have a maximum severity rating of Critical with the other ten having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Thanks to the entire MSRC Engineering team for the hard work on these cases!!

- Jonathan Ness, MSRC Engineering

This month we released MS11-090 to address a vulnerability in the Microsoft Time component (CVE-2011-3397), which features the deprecated time behavior that is still supported in IE6. We would like to provide further information about this issue and help explain why a “binary behavior kill bit” is the appropriate course of action.

Which products are affected?

The vulnerable component was removed from IE7 and later browsers. IE6 is the only supported browser that is affected.

What is, or was, the time behavior?

The time behavior is a feature of HTML+TIME 1.0, which was released in IE5. It provides an active timeline for enabling animated content.

Why is CVE-2011-3397 included in the ActiveX Kill Bits bulletin (MS11-090) instead of in the cumulative IE bulletin (MS11-099)?

The most appropriate remedy for this issue is to issue a kill bit to disable the deprecated binary behavior.

What is the binary behavior kill bit?

Usually, the kill bits we issue are targeted toward disabling specific ActiveX Objects. For example, the following registry key sets a kill bit for an ActiveX object on x86-based systems:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"Compatibility Flags"=dword:00000400

The binary behavior kill bit is very similar. To set a kill bit for a particular binary behavior, you can use:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"Compatibility Flags"=dword:04000400

The highlighted bit notifies IE to never load binary behaviors from the specific CLSID. The registry key for x64-based systems is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control 

x86 IE:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

For more information about the kill bit, please refer to David Ross’s excellent Kill-Bit FAQ Series. It will be updated shortly to discuss the binary behavior kill bit.

Special thanks to Kwan-Leung Chan and Eric Lawrence on the IE team.

- Chengyun Chu, MSRC Engineering

Today, we released MS11-087 addressing an issue in the font parsing subsystem of win32k.sys, CVE-2011-3402. The bulletin received a Critical rating due to a potential browser-based attack vector. We have not seen the browser-based attack vector exploited in the wild. The bulletin includes a workaround to disable this remote code execution attack surface. You might consider applying the workaround even after applying security update MS11-087, simply to reduce your attack surface. This blog explains how in more detail.

Issue Summary

This vulnerability has been used to drop the Duqu malware. An insufficient bounds check within the font parsing subsystem of win32k.sys could potentially allow a malformed font to corrupt ring0 memory. In the case of the Duqu dropper, a malformed font embedded inside an Office Word document triggered this memory corruption vulnerability to jump to attacker shellcode.

To be clear, Duqu did not exploit the browser-based attack vector. As far as we know, this vulnerability has only been exploited via a custom font embedded within an Office document. However, attackers could potentially construct a malicious font in such a way that it could be embedded in a webpage. There is an easy workaround to block that particular attack surface.

Protecting your environment

The best option for protecting against this particular vulnerability is to apply the MS11-087 security update. It will comprehensively address this issue.

If you are unable to apply the update right away and/or are concerned primarily about the browser-based attack surface, you might consider simply disabling IE’s ability to download custom fonts entirely. The side effect of this approach is potential display and layout glitches on web pages that leverage custom fonts to display text in interesting new ways. However, the vast majority of web sites use fonts included with Windows or use text layout tricks that do not require this particular custom font technology. Opening a web page that embeds a custom font after you have applied the workaround will cause Internet Explorer to display the text using a built-in font. Below, you can see the user experience of browsing to a webpage that leverages a custom font:

Figure 1: Webpage using custom, downloaded font

Figure 2: Same webpage displayed after workaround is applied

Workaround Steps

You can disable custom font download in Internet Explorer either interactively (using the GUI) or via Group Policy or a Management Deployment Script across multiple machines.

- Interactive deployment

• Launch Internet Explorer
• On the ‘Tools’ Menu select ‘Internet Options’.
• Click the ‘Security’ Tab.
• To change the setting for the ‘Internet’ zone select ‘Internet’ and press the ‘Custom Level’ button.
• Scroll down to the ‘Downloads’ section and select ‘Prompt’ or ‘Disable’ for the ‘Font Download’ security setting.
• Press OK to close the ‘Security Settings’ dialog box.
• Press OK to close the ‘Internet Options’ dialog box.

- Group Policy deployment

NOTE: The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain. It is assumed that the reader will know how to deploy the steps below for their particular environment.

• · Open the group policy management and configure it to work with the appropriate group policy object (i.e. local machine, OU or domain GPO).
• · Navigate to the following node:
  • o User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Security.
• · Double click ‘Security Zones and Content Rating’.
• · On the ‘Security Zones and Content Rating’ dialog box select ‘Import the current security zones and privacy settings’ and then click the ‘Modify settings’ button.
• · NOTE: This will create a group policy for Internet Explorer based on the settings of the currently logged in user.
• · On the ‘Internet Properties’ dialog box ensure the ‘Internet’ zone is selected and then press ‘custom level’.
• · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
• · Press OK to return to the ‘Internet Properties’ dialog box.
• · On the “Internet Properties’ dialog box select the ‘Local Intranet’ zone and then press ‘custom level’.
• · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
• · Press OK to return to the ‘Internet Properties’ dialog box.
• · Press OK to return to the ‘Security Zones and Content Ratings’ dialog box.
• · Press OK to return to the group policy management console.
• · Refresh the group policy on all machines or wait for the next scheduled group policy refresh interval for the settings to take effect.

- Managed Deployment Script deployment

This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script. For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch. For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/

To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00
; Zone 1 is the local intranet zone
; 1604 is the Font download policy
; dword:00000001 sets the policy to prompt
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1604"=dword:00000001
; Zone 3 is the internet zone
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1604"=dword:00000001

To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00
; Zone 1 is the local intranet zone
; 1604 is the Font download policy
; dword:00000003 sets the policy to disable
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1604"=dword:00000003
; Zone 3 is the internet zone
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1604"=dword:00000003

Bottom Line

We encourage you to first apply the security update to address this particular vulnerability. However, you might consider also blocking the browser-based font attack surface from within Internet Explorer as a good ‘attack surface reduction’ step. The tiny minority of web pages that embed custom fonts may display differently but you will be protected from any potential browser-based attack vectors leveraging custom fonts within Internet Explorer.

- Chengyun Chu and Jonathan Ness, MSRC Engineering

On behalf of the ECS team at Microsoft, I am pleased to announce the release of Hotfix Rollup 4 for Forefront Protection 2010 for Exchange Server.

On December 5th Microsoft shipped Hotfix Rollup 4 for Forefront Protection 2010 for Exchange Server (FPE). For a complete list of fixes included in this rollup, along with directions for download, please see our Knowledge Base article: Hotfix Rollup 4 for Microsoft Forefront Protection for Exchange.

As the installer runs, server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

With the variety of Forefront configuration options available, often our users have questions about how our products work together to form a comprehensive server protection solution. Microsoft’s Forefront Protection 2010 for Exchange Server engineers recently sat down to answer some of the most frequently asked questions about FPE. If you are interested in finding out more about FPE and Edge transport integration, reporting, policies, or spam quarantine access rights, head over to the updated Forefront Protection 2010 for Exchange Server (FPE 2010) FAQ on the TechNet wiki. You will find answers not only to users’ scenario questions but also a high-level overview of the Forefront Protection 2010 for Exchange Server product.

After looking through the FAQ, let us know what you think by leaving a comment on the wiki page or this blog post. Do you have questions we didn’t cover in the FAQ? Check out the full list of help documents in the TechNet FPE 2010 library at Microsoft Forefront Protection 2010 for Exchange Server.

Timothy Rich - Technical Writer for Office User Assistance

This month we released MS11-083 to address an externally found reference counter issue in TCP/IP stack. Here we would like to give further information about the exploitability of this vulnerability.
 
Vulnerability
The vulnerability presents itself in the specific scenario where an attacker can send a large number of specially crafted UDP packets to a random port that does not have a service listening. While processing these network packets it is observed that some used structures are referenced but not dereferenced properly. This unbalanced reference counting could eventually lead to an integer overflow of the reference counter.
  
Effects of reference count wrap around
With the above described vulnerability, when the system is deluged with network packets, the reference counter in the structure will keep incrementing and eventually wrap around.

If a dereference happens just after the counter has wrapped to zero, the structure will be freed. Depending on the timing conditions, four scenarios are possible:
• The memory is still mapped and contains the old data. No crash results and the system works as normal.
• The memory is unmapped and the system crashes when it is referenced. This results in a system denial-of-service.
• The memory is re-allocated for the same structure. No crash results and the system works as normal.
• The memory is re-allocated for a different structure. This could result in a system crash, or if attacker-controlled data is present, could lead to memory corruption or remote code execution.
 
Exploitability 
While the last scenario can theoretically lead to RCE, we believe it is difficult to achieve RCE using this vulnerability considering that the type of network packets required are normally filtered at the perimeter and the small timing window between the release and next access of the structure, and a large number of packets are required to pull off the attack. As a result, we assign an Exploitability Index of "2" for this vulnerability.

Ali Rahbar, Mark Wodrich from MSRC Engineering, Gangadhara Swamy from IDC.

Special thanks to Jeremy Tinder from MSRC.

We recently added a topic to the TechNet Wiki called Forefront Protection Server Management Console FAQs and Best Practices. We wanted to make available this troubleshooting and best practices content for our customers using FPSMC, which allows you to manage multiple instances of Forefront Protection 2010 for Exchange Server. We hope you find it helpful. If you are a member of the TechNet wiki community, feel free to add your own FPSMC tips and tricks.

Today we released eight security bulletins. Two have a maximum severity rating of Critical with the other six having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

Today the MSRC released Microsoft Security Advisory 2588513 alerting customers to a new vulnerability reported in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability.

Is SSL broken?

Yes and no. Yes means that under certain circumstances, the attacker can decrypt the encrypted SSL traffic. No means that there are significant mitigating factors that would make the attacks difficult or impossible.

Attack vector

In the advisory, it is mentioned that the vulnerability could allow the attacker to decrypt the SSL 3.0/TLS 1.0 encrypted traffic. While the affected component is a Windows component, the primary vector is to attack the browser’s use of the HTTPS protocol to intercept sensitive information, such as the session cookie of the HTTPS session.

Mitigation

Based on our current investigation, the following are mitigating factors that would make any potential attack via currently known exploit vectors difficult or impossible:

• The HTTPS session must be actively attacked by a man-in-the-middle; simply observing the encrypted traffic is not sufficient.
• The malicious code the attacker uses to decrypt the HTTPS traffic must be injected and run within the user’s browser session.
• The attacker’s malicious code needs to be treated as from the same origin as the HTTPS server in order to it to be allowed to piggyback on an existing HTTPS connection. Most likely it requires the attacker to exploit another vulnerability to bypass the browser’s same origin policy.

Therefore, if the user closes all existing HTTP tabs and untrusted HTTPS tabs, then browses to the trusted HTTPS site, such as the log-in page of hotmail.com in a new browser session, and logs out of that HTTPS session before browsing any other HTTP sites or untrusted HTTPS sites, the user will NOT be at risk for this attack.

Workaround

One workaround we would encourage the web server administrators to do is to give a higher priority for the RC4 Cipher Suite than CBC since the attack only affects cipher suites that use CBC. By giving a higher priority for RC4 on the server, RC4 instead of CBC will be used in the security communication since all of windows clients support RC4, unless put in FIPS compliant configuration. Please refer to this MSDN article to learn how to perform this operation via group policy. It is an effective option for web server administrators using Windows Vista or Windows Server 2008 and later platforms.  We recommend putting TLS_RSA_WITH_RC4_128_SHA as the top of the priority list, as indicated in the following image:

We would also encourage users and web administrators to enable the newer security protocols, such as TLS 1.1, on both the client side and the server side. If the browser and web server both enable TLS 1.1, the HTTPS traffic uses TLS 1.1 protocol instead of SSL 3.0/TLS 1.0, and thus won’t be affected by such attacks. TLS 1.1 protocol is supported in Windows 7 and Windows 2008 R2.

To ENABLE TLS 1.1 for Internet Explorer and other WinINET-based applications running on Windows 7 and Windows Server 2008 R2, please click here: 

To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here: 

If you would like to revert the changes made by these FixIt's, you can find a corresponding DISABLE Fixit for both the client side and server-side changes at http://support.microsoft.com/kb/2588513.

Why TLS 1.1 is not enabled by default?

The main reason to not enable TLS 1.1 by default is due to compatibility problems. We need more servers to implement HTTPS protocols correctly so we can enable TLS 1.1 by default in the client in the future versions of IE. We will work hard to drive adoption of TLS 1.1 or TLS 1.2 as an industry-wide effort.

Special thanks to Nasko Oskov and Eric Lawrence.

Update Sep 27 - Mitigating factors list applies to all currently known attack vectors.  Thanks for the suggestion to clarify, Juliano.

- Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering

Last week, we released Security Advisory 2607712, notifying customers that fraudulent digital certificates had been issued by certificate authority DigiNotar. We’d like to follow up on that notification in this blog post by explaining more about the potential risks and actions you can take to protect yourself from any potential attacks that would leverage those fraudulent certificates.

• Scope of the risk
• Vulnerable configurations
• What Microsoft is doing to protect you
• What you can do to protect yourself
• Additional protections built-in to Windows Update

Scope of the risk

Digital certificates issued by a trusted Certificate Authority (CA) establish the identity of a computer. Protocols that assure your privacy, such as SSL (HTTPS) and TLS, leverage a server’s digital certificate to ensure that no third party can eavesdrop on or tamper with conversations between a client and the server. Clients and servers establish their identity via a digital certificate. Clients make a decision to trust the identity of the server because they trust that a CA verifies the legitimacy of the person or company requesting the certificate. If a trusted CA were to be compromised or tricked into issuing fraudulent certificates, a malicious attacker could potentially request and be granted a digital certificate that would allow the attacker to participate in HTTPS conversations, snooping on or tampering with the contents.

For an attack to be successful, an attacker must have been issued a digital certificate for the server or domain to which the client is initiating a connection. Also, the attacker must be able to tamper with the conversation in progress. Practically speaking, this tampering can happen in one of three ways:

• The attacker is on your local network (open wireless network, for example);
• The attacker owns or operates the network infrastructure between the victim client and the listening server; or
• The attacker controls the DNS server used by your ISP, or can influence your choice of DNS server via DHCP responses if a client gets DNS settings via DHCP.

Without this type of “man-in-the-middle” access, an attacker would be unlikely to be successful in carrying out an attack.

In this particular case, we were originally aware of fraudulent certificates issued by DigiNotar for *.google.com and have since become aware of fraudulent certificates issued for *.microsoft.com, *.windowsupdate.com, www.update.microsoft.com, and a number of other domains for which conversation privacy is extremely important. Windows Update is a special case addressed later in the blog; however, suffice it to say that if the attacker had one of those certificates and had man-in-the-middle access to your network traffic, they could potentially snoop on (or change the contents of) conversations between you and any of those domains.

Vulnerable configurations

All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.

Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.

However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.

Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.

What Microsoft is doing to protect you on Windows Vista and later platforms

Microsoft has updated the Certificate Trust List (CTL) hosted on Windows Update to remove DigiNotar as a trusted root Certificate Authority. Attacks targeting Internet Explorer users on Windows Vista and later platforms any time after August 29th will likely fail. However, we should note that systems having previously encountered DigiNotar certificates may have cached DigiNotar as a trusted root Certificate Authority. This cached list is updated client-side every seven days. Therefore, the last date on which any attack targeting Internet Explorer users on Windows Vista and later platforms might possibly be successful is September 5th.

What Microsoft is doing to protect you on Windows XP and Windows Server 2003

We are currently preparing an update for Windows XP and Windows Server 2003 platforms which will add DigiNotar to our Untrusted Certificate Store. This update will be available soon.

What you can do to protect yourself

First, as indicated in the security advisory, we recommend keeping Microsoft software updated. If you’re able to do so, opt into Automatic Updates to automatically get the Windows XP and Windows Server 2003 updates when they become available.

Second, you can choose to delete the DigiNotar root from the root store manually. You might consider doing this if you believe the risk to your network or system is urgent and you would like to take action before the Windows XP and Windows Server 2003 update becomes available. After doing this, you’ll also need to clear the local cache. The steps for both removing the DigiNotar root from the trusted root CA store and clearing the cache are listed below.

Step 1: Remove the DigiNotar Root from the trusted root CA store

• Click Start, click Start Search, type mmc, and then press ENTER.
• On the File menu, click Add/Remove Snap-in
• Under Available snap-ins, click Certificates, and then click Add
• Under This snap-in will always manage certificates for, click Computer account, and then click Next
• Click Local computer, and click Finish
• If you have no more snap-ins to add to the console, click OK
• In the console tree, double-click Certificates
• Double-click the Trusted Root Certification Authorities store and click on Certificates to view all certificates in the store
• Select the two DigiNotar Root CA certificates. You can confirm the right certificates by checking their thumbprints which should be “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
• Right-click the certificates and select Delete

To perform the above steps from the command-line, you can use the certutil.exe tools as follows:

• certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
• certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - http://technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints "c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c" and "43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3".

Step 2: Clear the cache to remove any older cached CTL

The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at http://support.microsoft.com/kb/2328240

--

As indicated above, most customers on Windows Vista and later platforms are already protected due to the updated Certificate Trust List on Windows Update, which is checked when Windows encounters a new root Certificate Authority. To ensure that DigiNotar has not been cached locally as a trusted root CA, you can clear the local cached CTL as explained above. A fresh CTL will automatically be downloaded the next time Windows encounters a new root CA.

There is one final edge case to consider that will not be automatically protected:

• If you are an enterprise customer having Windows Vista and later workstations; and
• If you have disabled the auto root update mechanism via the group policy option; and
• If you have manually added DigiNotar as a trusted root authority –

  Then you likely will want to add the DigiNotar roots to the Untrusted Certificate Store via group policy.

Additional protections built-in to Windows Update

Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate.

Thanks to Yogesh Mehta, Shain Wray, Charles Anthe, and Mark Wodrich for the help with this blog post.

Updated Sept 5:  Added certutil.exe command line example.  Thanks Uwe Wizovsky for the tip.

- Jonathan Ness, MSRC Engineering

Today we released 13 security bulletins. Two have a maximum severity rating of Critical, nine have a maximum severity rating of Important, and two have 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 MS11-058 to address two vulnerabilities in the Microsoft DNS Service. One of the two issues, CVE-2011-1966, could potentially allow an attacker who successfully exploited the vulnerability to run arbitrary code on Windows Server 2008 and Windows Server 2008 R2 DNS servers having a particular DNS configuration. We’d like to share more detail in this blog post and help you make a risk decision for your environment.

• Affected DNS configuration
• Unlikely to be exploited for code execution
• More detail about the attack vector
• Answers to common questions

Affected DNS configuration

This vulnerability affects DNS servers that allow attackers to issue lookup requests for another domain name in a way that would cause the DNS server to request the answer from a malicious DNS server. Specifically, if an attacker can cause a DNS server to request a DNS NAPTR resource record from a malicious DNS server, the attacker could potentially trigger the vulnerability described by CVE-2011-1966 on the DNS server of which the attacker is making the request.

One common affected configuration is a caching or relay DNS server on a corporate network where a malicious user is lurking. Less likely to be affected are authoritative DNS servers hosting zones exposed to the Internet, where recursion is often disabled. For example, anyone on the Internet can connect to the microsoft.com authoritative DNS server, but that server will not relay requests to a malicious DNS server.

More information about the DNS protocol, DNS recursion and forwarding:

• How DNS query works
• Understanding forwarders

Unlikely to be exploited for code execution

An affected system receiving a malicious NAPTR resource record from a malicious DNS server will result in heap memory corruption. For this reason, the security bulletin describes this issue as having the potential for remote code execution. However, due to the nature of this vulnerability, it is far more likely to result in a denial-of-service condition where the DNS service terminates unexpectedly and less likely to result in remote code execution.

This is due to the type of vulnerability and the platform mitigations provided by Windows Server 2008. The issue is a sign-extension vulnerability where a small negative number is expanded to a larger type without proper checks. Later, this large negative number is used as a memcpy count to populate a heap buffer. The copy length will always be at least 0x80000000 bytes long so the copy operation itself will likely fail in the absence of 2+ GB of memory available to be copied. Even if an attacker is able to successfully populate memory for the copy to succeed and massage the heap to gain control of the process, the platform mitigations of ASLR, DEP, and the heap metadata protection must still be overcome before malicious code could be run. And, finally, an attacker has only three opportunities to exploit a particular DNS server - the service control manager will no longer restart it after it crashes three times. While code execution is theoretically possible, we think a denial-of-service is most likely. Hence, we have rated the likelihood of exploit code for remote code execution appearing in the next 30 days as “3 – Functioning Exploit Code Unlikely”.

More detail about the attack vector

Due to the distributed nature of the DNS protocol, DNS servers configured to resolve names on behalf of client and applications usually support recursion (unless explicitly disabled by Admin), allowing them to talk and exchange information with other DNS Servers. The vulnerability exists in the way a Microsoft DNS Server parses NAPTR records from a remote DNS server. Here is an example, assuming the attacker controls the contoso.com DNS server and has configured it to return malicious NAPTR record data:

The victim DNS server in this case could be an unpatched Microsoft DNS Server with recursion / forwarding enabled. The attacker knows that the victim server will communicate with the contoso.com DNS Server to fetch the DNS NAPTR record requested by the client. The attacker’s malicious DNS Server then responds with the malformed NAPTR data which triggers a crash on the victim DNS Server. The victim server crashes due to the CVE-2011-1966 vulnerability while attempting to parse the malicious NAPTR record content. The crash happens only for a particular set of data for NAPTR records.

Answers to common questions

Q: I don’t host NAPTR record; is this patch applicable to my deployment?

A: Yes. As indicated above, the problem lies in the code that parses the malformed data while receiving it from other sources, not while hosting it. If your DNS Servers have recursion enabled and allows potential attackers to issue requests, this patch should be applied.

Q: I host only authoritative zones on my DNS server and have disabled recursion. Is it vulnerable?

A: This configuration is technically not vulnerable. However, due to the dynamic nature of networks, we recommend that you patch all DNS servers to prevent future configuration changes from opening attack surface.

Q: Are enterprise deployments vulnerable to this attack?

A: Enterprise networks that use a web proxy and do not allow enterprise DNS server to resolve Internet names would certainly be at reduced risk. One attack vector remaining in that case is that of an attacker with minor access rights on an enterprise network bringing up a malicious DNS server. However, they will likely face difficulty in coercing the real enterprise DNS server to direct queries to it without some level of administrative privilege.

Acknowledgements

Thanks Bruce Dang, Saaransh Bagga, Shreyas Behera, Jeremy Tinder, Nicolas Guigo, Matt Miller, and Jeff Westhead for contributing to this blog post.

- MSRC Engineering

How can you protect yourself, your business, and your customers when faced with an unknown or unpatched software vulnerability? This question can be difficult to answer but it is nevertheless worthy of thoughtful consideration. One particularly noteworthy answer to this question is provided in the form of exploit mitigation technologies such as DEP and ASLR, which are designed to make it difficult and costly for an attacker to exploit a software vulnerability. The protection offered by exploit mitigations is generally independent of a single vulnerability and therefore opens the door to protecting against the exploitation of vulnerabilities that may currently be unknown or that have not yet been addressed through a security update.

The virtues of exploit mitigations are something that we strongly believe in at Microsoft. This belief is clearly demonstrated by the exploit mitigation features we have added to our products over time (DEP, ASLR, /GS, etc) and through policies in the Microsoft’s Security Development Lifecycle (SDL) that require product teams to leverage these features. Although many of these technologies have been available for quite some time, we have found that adoption by third-party software vendors has been slower than we would like. We have also heard from many enterprise administrators that they have difficulty justifying the use of exploit mitigations or are hesitant to make use of them because of performance and compatibility concerns. This is something we would like to change.

In the interest of helping to encourage adoption within the enterprise and by third-party software vendors, we have published a paper entitled Mitigating Software Vulnerabilities. This paper provides justification for the use of exploit-mitigation technologies and enumerates the set of technologies that are available today. The description of each technology includes an overview of how the technology works and what performance, compatibility, and deployment considerations should be taken into account, if any. The availability of each technology is also presented for supported operating system and compiler versions. The paper concludes with a set of recommended actions for software developers, enterprise administrators, and home and business users. In particular, we recommend that the Enhanced Mitigation Experience Toolkit (EMET) be used to evaluate the impact of enabling certain mitigations and to protect systems and applications that may be at-risk.

It is our hope that this paper will demonstrate the need for exploit mitigations and help encourage adoption of exploit mitigation technologies within the Windows ecosystem. We encourage you to check back frequently for more information about upcoming security tools and technologies at http://www.microsoft.com/security/msec.aspx.

- Matt Miller, Microsoft Security Engineering Center

The single Critical vulnerability in today’s batch of security updates addresses an issue in the Bluetooth stack. Your workstations’ risk to this vulnerability varies, depending on a number of factors. I’d like to use this blog post to outline those risk factors.

How can I protect my system?

The best way to protect any potentially vulnerable system is to apply the MS11-053 security update. If you are not able to apply the security update, you can close off the attack surface by preventing any Bluetooth device from connecting to your computer. The graphic below shows the Windows 7 Bluetooth Settings option for doing so. Side effect: Your Bluetooth mouse or headset will stop working until you re-allow Bluetooth devices to connect to your computer.

Am I vulnerable to remote code execution attacks today?

Short answer: Probably not. And here’s why:

Exploitability: First, we assigned this vulnerability with an Exploitability Index rating of “2”. We believe it will be difficult to build a reliable exploit for code execution using this vulnerability. It’s more likely that attackers will discover a way to cause a system denial-of-service (“bugcheck” / “bluescreen”) using this vulnerability.

Discoverability: Secondly, your system’s 48-bit Bluetooth address is not “discoverable” by default. Notice in the Bluetooth Settings screenshot above that Bluetooth devices are not allowed by default to “find” this computer. If your system were “discoverable,” it would respond to attacker SDP queries with its Bluetooth address. But in the default state, an attacker must obtain your Bluetooth address another way – either via bruteforcing it or extracting it from Bluetooth traffic captured over-the-air.

Extracting Bluetooth address by sniffing traffic: If you have paired a Bluetooth peripheral and are actively communicating, it is hard but not impossible to extract the Bluetooth address from the traffic sent over-the-air. A device is available on the market for $10,000 - $30,000 to do this in about 5 minutes. Research continues to advance in this space and we expect in years to come that this will become quicker for attackers. But for now, it remains difficult but not impossible to extract the Bluetooth address from over-the-air traffic.

Proximity: Finally, while this vulnerability is exposed remotely, it is not reachable over the Internet. An attacker must be physically nearby to target you. Again, recent research has widened the definition of “nearby” for Bluetooth but suffice to say that an attacker would need to be within line-of-sight. This nearby attacker then could spend several hours brute-forcing your Bluetooth address and attempting to exploit the vulnerability.

This combination of factors leads us to believe that systems are unlikely to be exposed to reliable remote code execution exploits via this vulnerability in the next 30 days.

Thanks to Krupa Poobala-chandran from the Windows Sustained Engineering team for the help yesterday afternoon pulling this blog post together.

- Jonathan Ness, MSRC Engineering

Today we released security update MS11-056 to address vulnerabilities in the Windows Client/Server Runtime Subsystem (CSRSS) and Console Host (conhost.exe). We also closed an internally found elevation of privilege attack vector on Windows 7 and Windows Server 2008 R2, significantly reducing the opportunity for any console issues discovered in the future to result in elevation of privilege on those platforms.

What’s the risk?

An attacker already able to run code on a system could use the vulnerabilities addressed in MS11-056 to elevate privileges on the system. On Windows XP and Windows Vista systems, an attacker able to execute code at a low privilege could potentially execute arbitrary code as SYSTEM within the context of the Client/Server Runtime Subsystem. On Windows 7 and Windows Server 2008 R2 systems, the affected code was moved to a different process (conhost.exe) running at the same privilege level as the logged-in user. [1] Therefore, an attacker could potentially execute arbitrary code in the context of another Console Host process if there is a higher privileged process with a console.

Details

The vulnerabilities are caused by insufficient validation of specific console API messages. On Windows XP and Windows Vista, the handling of Console API messages happens inside the Client/Server Runtime Subsystem, while on Windows 7 and Windows Server 2008 R2 a separate conhost.exe process is created running with the same credentials as the associated console application. [1]

Internal research discovered a scenario on Windows 7 and Windows Server 2008 R2 in which a memory corruption issue inside Console Host still could lead to elevation of privileges. MS11-056 fixes the memory corruption vulnerabilities on Windows XP and Windows Vista and also closes this cross-user scenario on Windows 7 and Windows 2008 R2. Console Host memory corruption issues on Windows 7 and Windows Server 2008 R2 should now result “worst-case” in code running in the same context as the attacker already able to execute code directly.

-Richard van Eeden, MSRC Engineering

[1] http://blogs.technet.com/b/askperf/archive/2009/10/05/windows-7-windows-server-2008-r2-console-host.aspx

The Khronos Group’s WebGL technology is a cross-platform, low-level 3D graphics API for the web. Recently, Context Information Security published two reports critical of the WebGL technology, WebGL – A New Dimension for Browser Exploitation and WebGL – More WebGL Security Flaws.

One of the functions of MSRC Engineering is to analyze various technologies in order to understand how they can potentially affect Microsoft products and customers. As part of this charter, we recently took a look at WebGL. Our analysis has led us to conclude that Microsoft products supporting WebGL would have difficulty passing Microsoft’s Security Development Lifecycle requirements. Some key concerns include:

• Browser support for WebGL directly exposes hardware functionality to the web in a way that we consider to be overly permissive

  The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.

• Browser support for WebGL security servicing responsibility relies too heavily on third parties to secure the web experience

  As WebGL vulnerabilities are uncovered, they will not always manifest in the WebGL API itself. The problems may exist in the various OEM and system components delivered by IHV’s. While it has been suggested that WebGL implementations may block the use of affected hardware configurations, this strategy does not seem to have been successfully put into use to address existing vulnerabilities.

  It is our belief that as configurations are blocked, increasing levels of customer disruption may occur. Without an efficient security servicing model for video card drivers (eg: Windows Update), users may either choose to override the protection in order to use WebGL on their hardware, or remain insecure if a vulnerable configuration is not properly disabled. Users are not accustomed to ensuring they are up-to-date on the latest graphics card drivers, as would be required for them to have a secure web experience. In some cases where OEM graphics products are included with PCs, retail drivers are blocked from installing. OEMs often only update their drivers once per year, a reality that is just not compatible with the needs of a security update process.

• Problematic system DoS scenarios

  Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry. Although mitigations such as ARB_robustness and the forthcoming ARB_robustness_2 may help, they have not proven themselves capable of comprehensively addressing the DoS threat. While traditionally client-side DoS is not a high severity threat, if this problem is not addressed holistically it will be possible for any web site to freeze or reboot systems at will. This is an issue for some important usage scenarios such as in critical infrastructure.

We believe that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities. In its current form, WebGL is not a technology Microsoft can endorse from a security perspective.

We recognize the need to provide solutions in this space however it is our goal that all such solutions are secure by design, secure by default, and secure in deployment.

- MSRC Engineering

Today we released 16 security bulletins. Nine have a maximum severity rating of Critical and seven have a maximum severity rating of Important. This release addresses several publicly disclosed vulnerabilities. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Please let us know (switech at microsoft dot com) if you have any questions about these updates. 

Jonathan Ness, MSRC Engineering

Today we have released MS11-044 to address CVE-2011-1271, a remote code execution vulnerability in the .NET framework. Here we would like to provide more technical information about this vulnerability and why we believe this issue to be unlikely to be exploited.

This root cause of CVE-2011-1271 is that there was a bug in the JIT compiler which would cause it to mistakenly determine that a given object is always null (or non-null) and would omit certain checks.

For example:

                                     if ((value == null || value == new string[0]) == false)
00000027  test        esi,esi               ; value == null?
00000029  je          00000075 
0000002b  xor         edx,edx               ; new string[0]
0000002d  mov         ecx,6D913BD2h 
00000032  call        FFD20BC8 
00000037  cmp         eax,esi               ; value == new string[0]?
00000039  je          00000075 
{
Console.WriteLine("Post-check Value is: " + value);
0000003b  mov         ecx,dword ptr ds:[03532090h]  ; "Post-check value is: "
00000041  xor         edx,edx               ; Wrong here.
00000043  call        6D70B7E8              ; String.Concat()
00000048  mov         esi,eax               ; 
0000004a  call        6D72BE08              ; get Console.Out
0000004f  mov         ecx,eax 
00000051  mov         edx,esi 
00000053  mov         eax,dword ptr [ecx] 
00000055  call        dword ptr [eax+000000D8h]     ; Console.WriteLine()

At offset 0x41, the optimizer has incorrectly concluded that value will always be null so it directly passes a null to String.Concat().

For CVE-2011-1271, the JIT compiler can introduce a logic flaw when running C# or IL code sequences very similar to those describe above. Depending on the .NET application’s business logic, if the NULL check (or non-NULL check) is used to make a security decision, for example the check of certain credentials, and if the attacker controlled data may leverage directly or indirectly this missing logic and gain advantages based on this, then there is a possibility of remote code execution.  However, we do not believe this to be a common case for the majority of deployed .NET applications.

Special thanks to Reid Borsuk in .NET team.

Fermin Serna and Chengyun Chu, MSRC Engineering

Today, we released MS11-050, a cumulative security update for Internet Explorer to address several vulnerabilities in IE9.

The following table lists the CVEs included in MS11-050, and whether each affects IE8 or IE9.

As shown above, only a minor fraction of vulnerabilities affecting IE8 (and earlier versions of the browser) would still affect IE9. This is due to various factors related to security work that happened in IE8, ranging from deprecating obsolete features, to improving fuzzing tests in IE9 and so on. For example, CVE-2011-1255 is related to HTML+TIME, which was deprecated in IE9 development.

There are many beautiful things in IE9. Besides all these wonderful new features, we would also recommend you to update to IE9 if you can for security. :)

Chengyun Chu, MSRC Engineering

Today we are pleased to announce a new version of the Enhanced Mitigation Experience Toolkit (EMET) with brand new features and mitigations. Users can click here to download the tool free of charge. 

The Enhanced Mitigation Experience Toolkit enables and implements different techniques to make successful attacks on your system more difficult. EMET is designed to mitigate exploitation attempts (even of 0-days) by making “current” exploitation techniques harder and less reliable. Users interested in finding out more about EMET can read more here.

EMET has a proven track record of stopping real-life attacks, as we have detailed in our previous blog-posts here , here and here.

This release marks a big milestone for EMET since this is the first version that is available as an officially-supported product. Support will be forum based available here.

Today’s release comes with some new features:

• EMET is an officially-supported product through the online forum
• “Bottom-up Rand” new mitigation randomizes (8 bits of entropy) the base address of bottom-up allocations (including heaps, stacks, and other memory allocations) once EMET has enabled this mitigation.
• Export Address Filtering is now available for 64 bit processes. EAF filters all accesses to the Export Address Table which blocks most of the existing shellcodes
• Improved command line support for enterprise deployment and configuration
• Ability to export/import EMET settings
• Improved SEHOP (structured exception handler overwrite protection)  mitigation
• Minor bug fixes

I would like to thank Matt Miller for his work on EMET.

- Fermin J. Serna, MSRC Engineering

We have updated the Protecting your Exchange servers section of the Forefront Protection 2010 for Exchange Server (FPE) Planning and Architecture documentation to give you more information about how the product can protect your organization from messaging threats. Specifically, the Understanding spam processing section discusses how the product’s spam filtering layers (connection filtering, SMTP filtering, and content filtering) work, including more “under the hood” details about how specific types of spam are detected and removed.

We hope you find this new content to be helpful as you configure FPE to protect your Exchange messaging environment.

Tony Trivison - Forefront for Office User Assistance

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Forefront Protection 2010 for Exchange.

On April 18th Microsoft shipped Hotfix Rollup 3 for Forefront Protection for Exchange (FPE) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see our Knowledge Base article: Description of Hotfix Rollup 3 for Microsoft Forefront Protection for Exchange.

As the installer runs, server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Microsoft Forefront Security for Office Communications Server.

On April 18th Microsoft shipped Hotfix Rollup 3 for Microsoft Forefront Security for Office Communications Server (FSOCS) to provide a series of product enhancements. For a complete list of the enhancements included in this rollup, along with directions for download, please see our Knowledge Base article: Description of Hotfix Rollup 3 for Microsoft Forefront Security for Office Communications Server.

 As the installer runs, server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

 Rob McCarthy, Sr. Support Engineer

Hi All,

Just wanted to call to your attention that Wikipedia entries have been posted for the following Microsoft Forefront products:

• Forefront Protection 2010 for Exchange Server
• Forefront Online Protection for Exchange
• Forefront Protection 2010 for SharePoint
• Forefront Protection Server Management Console

Feel free to improve and expand upon this content.

Thanks,
Scott Floman
Technical Writer – Forefront for Office

As of January 18, 2011, Microsoft will be signing antivirus engines used by Antigen with a new certificate in order to continue to ensure secure and reliable virus-engine updates. This will require a new certificate implementation on any Windows 2000 server running Antigen 9.0.

Please see the following Knowledge Base article for clear and detailed instructions on implementing this new certificate: As of 18th January 2011, a new certificate is required to continue updating virus engines for Antigen 9 installed on Windows Server 2000

Rob McCarthy, Sr. Support Engineer

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 1 for Microsoft Forefront Protection 2010 for SharePoint.

On January 17th Microsoft shipped Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint (FPSP) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the Knowledge Base article: Description of Hotfix Rollup 1 for Forefront Protection for SharePoint

As the installer runs, Server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

On behalf of the Forefront Server Protection team at Microsoft, I am pleased to announce the release of Forefront Protection Server Management Console 2010 (FPSMC).

On December 17th, 2010 Microsoft shipped the Forefront Protection Server Management Console (FPSMC) to provide centralized management for the Forefront Protection 2010 for Exchange Server and Forefront Protection 2010 for SharePoint servers in your environment. FPSMC provides multi-server management through a browser-based interface, and supports the following features:

·         Signature redistribution

·         Policy (configuration) deployment

·         Centralized incident, spam, and engine version reporting

·         Centralized quarantine management

·         Auto discovery of new servers

·         Integration with Forefront Online Protection for Exchange

For a complete list of features included in this free release, along with directions for download and installation, please go to: http://www.microsoft.com/downloads/details.aspx?FamilyID=31f66155-50f0-4665-adc0-de94da027ed7

Andrew Schiano

Software Development Engineer in Test

On behalf of the Security team at Microsoft, I am please to announce the release of Hotfix Rollup 2 for Microsoft's Forefront Security for Office Communications Server.

On December 15th, Microsoft shipped Hotfix Rollup 2 for Forefront Security for Office Communications Server (FSOCS) to provide a series of product enhancements and new features.

For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the following Knowledge Base article: http://support.microsoft.com/kb/2482040  

As the installer runs, server service restarts may be necessary, so please plan accordingly when applying this Hotfix Rollup.

Regards,

Robert McCarthy

CSS Microsoft Security

We would like to announce that the Forefront Protection Server Management Console 2010 (FPSMC) is currently scheduled to be available as a free download on December 17, 2010. Using a browser-based user interface, FPSMC allows administrators to centrally manage deployments of Forefront Protection 2010 for Exchange Server and Forefront Protection 2010 for SharePoint within their enterprise.

For more information on FPSMC, please see our previous update:

http://blogs.technet.com/b/fss/archive/2010/10/25/forefront-protection-server-management-console-2010-update.aspx

Andrew Schiano

Software Development Engineer in Test

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

To participate, please click here.

Carolyn Liu
Senior Program Manager, Forefront Server Protection

On behalf of the Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 2 for Microsoft’s Forefront Protection 2010 for Exchange.

On November 30th Microsoft shipped Hotfix Rollup 2 for Forefront Protection 2010 for Exchange to provide a series of product enhancements and new features.

For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the following Knowledge Base article: .http://support.microsoft.com/kb/2420647.

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

Regards,

Robert McCarthy
CSS Microsoft Security

My name is Andrew Schiano, and I work in Test for the Forefront Protection team. I would like to tell you a little bit about the soon-to-be released Forefront Protection Server Management Console 2010 (FPSMC). FPSMC provides centralized management for the Forefront Protection 2010 for Exchange (FPE) and Forefront Protection 2010 for SharePoint (FPSP) servers in your environment. FPSMC is expected to be available as a free download in Q4 2010.

FPSMC provides multi-server management through a browser-based interface, and supports the following features:

Signature redistribution

The signature redistribution job is used to deploy antivirus signature updates to the FPE/FPSP servers in an environment. The most efficient way to update engine signatures on all your servers is to create a redistribution job to download them to the FPSMC server. The FPSMC server is then used as the retrieval point for all the other servers in the environment.

Policy (configuration) deployment

FPSMC supports deploying a centralized set of configuration settings to one or more FPE or FPSP servers in your environment. This is accomplished by configuring one of your FPE/FPSP servers to the desired configuration and then exporting these settings in xml format.  The xml file is then imported into FPSMC, which can deploy these same settings to your other FPE/FPSP servers.

Patch deployment

FPSMC supports deploying FPE and FPSP roll ups and service packs. Patch packages can either be .MSP or .EXE file types.

Centralized incident reporting

The Incident Detection report presents data about the number of malware incidents and filter matches over a period of time on one or more managed servers. This includes the five most common malware types detected in your organization and the most recent detection date and time.

Centralized spam reporting

The Spam Detection report presents data about the number of spam messages blocked by FPE. This includes a pie-chart breakdown by filter type and a line graph showing the number of spam messages detected over time.

Centralized engine versions reporting

The Engine and Definition Versions report presents data about the antivirus engine versions and definitions on selected servers running FPE and FPSP. This report compares the current engine versions of the managed servers to determine which, if any, of your signatures are out of date.

Quarantine management

FPSMC supports retrieving quarantine data from managed Forefront Protection servers for local analysis and management, including delivering Exchange quarantine and restoring SharePoint quarantine.

Integration with Forefront Online Protection for Exchange (FOPE).

If you are using FOPE in your organization, you can use FPSMC to access the FOPE Administration Center to monitor your email flow. FPSMC provides access to the FOPE home page, quarantine, reports, and mail tracing facilities.

Auto discovery of servers

On a nightly basis, FPSMC will automatically detect new FPE and FPSP servers that have been added to your network.

Exchange Clusters -- CCR, SCC, and DAG 
FPSMC supports clustered Exchange servers, including E14 Database Availability Groups.

FPSMC will initially be available in English.  Localized versions in all 11 languages (Chinese-Simplified, Chinese-Traditional, English, French, German, Italian, Japanese, Korean, Portuguese-Brazil, Russian, and Spanish) will be released at a later date (to be announced).  

Thank you for your time, and I hope you found this article helpful.

Andrew Schiano

Software Development Engineer in Test

On behalf of the Forefront Server Protection team at Microsoft, I am pleased to announce the release of Forefront Security for Exchange Server (FSE) SP2 Rollup 3 and Forefront Security for SharePoint (FSSP) SP3 Rollup 3.

On October 8th, 2010 Microsoft shipped both builds to address a performance issue with version 8 of the Kaspersky antivirus engine.

For a detailed description of the updates please see the following Knowledge Base articles:

• Forefront Security for Exchange Server SP2 RU3: http://support.microsoft.com/kb/2420644
   
• Forefront Security for SharePoint SP3 RU3:  http://support.microsoft.com/kb/2422053

As the installer runs, server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup. 

Regards,

Robert McCarthy
Sr. Support Engineer
Microsoft Security

Microsoft is upgrading the multi-engine protection in all Forefront server security products to support a newer version of the antivirus engine.  The newer version will provide customers with improved scanning times and reduced signature file size. The new engine replaces the older engine. 

This new engine publishes update files in a subdirectory – the first engine in the Forefront engine mix to do so.  In order to accommodate this new publishing model, Microsoft is releasing a series of roll-ups that will:

•        Include the new antivirus engine

•        Ensure that any engine that publishes update files in a subdirectory will update correctly

Customers must install the rollups by Jan. 31, 2011.

Krishnan Venkatasubramanian

Senior Program Manager, Forefront Server Protection

Hello,

I’d like to take a moment and encourage each of you to check out Microsoft’s latest efforts to save you support costs and time.

Introducing Forefront Server RSS feeds:   Forefront Server RSS Feeds

By subscribing to our Forefront Server RSS feed, you allow Microsoft to give you the answers without having to ask the questions. Our goal is to provide insight into the top Forefront Server solutions as early as possible while saving you the time, resources, and effort of opening a support case. Our Solution Center list page ( Solution Centers ) provides an RSS icon in the upper right hand corner of your browser that points to the feed subscription page as well.

Empower yourself! Subscribe, ask questions, and provide feedback!

And remember, the bad guys never sleep and are busy developing new ways to wreak havoc on your network. Forefront developers work tirelessly to give you the latest means to defend against these attacks. Make sure you are incorporating these shields into your environment with the latest updates for Forefront Server products: Forefront Server Product Updates.

Rob McCarthy

Sr. Support Engineer
CSS Security

Some customers have reported problems downloading updates for the antivirus engine after installing the Forefront Server Security Management Console (FSSMC) Hotfix Rollup 5 and the Forefront Security for Exchange Server (FSE) Service Pack 2 Rollup 2.

The basic symptom is that antivirus engine updates fail. If you are experiencing this problem, please refer to the Microsoft support KB article #2410444 for information on how to resolve the problem. The KB will guide you through steps that will enable FSE to use the previous version of the antivirus engine and updates until a permanent fix is created.

If you continue having problems after trying the measures in the KB article, you should contact CSS for additional help.

Michel LaFantano

BPSG iX

Customers have been asking about how to best defend against the new e-mail virus Worm:Win32/VB.WF. This virus uses a link in the message body that looks like a link to a PDF file but is actually a link to a *.scr file. When you click the link, it begins sending e-mails using the GAL or contacts. (Information about the virus can be found on the Microsoft Malware Protection Center.)

If you are using the Cloudmark antispam engine in Forefront Protection 2010 for Exchange Server (FPE) or Antigen 9.2 AND your engine updates are up-to-date, your environment should be protected from this virus. If you are using Forefront Security for Exchange Server (FSE) or are not using the antispam features in FPE or Antigen, you can block these virus e-mails in several ways:

1.       During the Transport scan (Messages in Transport):

·      Subject line filtering on FPE (FSE doesn’t provide subject line filtering on the Transport Scan Job. This also assumes the messages do not contain an AV stamp.) The subject line of the e-mail is typically “Here you have”. You should create a subject line filter to block/delete messages using this subject line.

·      Exchange Transport rules. You can use Exchange transport rules to block messages based on their subject line.

2.       During the Mailbox scan (Messages in transit at the Store level via the Realtime scan job as well as cleaning up what’s already in the Store via the Scheduled scan job.)

·         Use FPE and/or FSE Realtime and Scheduled Scan subject line filters.

·         Use the Exchange PowerShell command: Get-TransportServer | Get-Queue | get-message | where{$_.MessageSubject -eq "Here you have"} | remove-message

For more information about using subject line filtering to stop this worm, please refer to this TechNet wiki article:

http://social.technet.microsoft.com/wiki/contents/articles/worm-win32-vb-wf-email-virus-defending-with-forefront-security-forefront-protection-antigen.aspx

Note: If you are using FPE, be sure to disable the “Scan only messages with attachments” option, which is enabled by default, so that it will actually scan and remove these e-mails as they do not contain attachments and will be overlooked if this option is not disabled.  You should also be aware of the “Scan only messages received in the last” configuration if you plan on running these scans this weekend.  By default, the Scheduled scan will only scan messages received within the past 2 days and may miss these messages depending on when you run or schedule the scan.

Michel LaFantano
BPSG iX

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 5 for the Forefront Server Security Management Console (FSSMC)!

Microsoft shipped Hotfix Rollup 5 for the FSSMC on August 26th, 2010.

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:  http://support.microsoft.com/kb/2302023

·         Description of Hotfix Rollup 5 for Forefront Server Security Management Console: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

Regards,

Robert McCarthy
Microsoft Security

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

•  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

Regards,

Robert McCarthy
Microsoft Security

Forefront Security for SharePoint (FSSP) includes a number of registry settings that control most of the configuration settings. The charts below provide information about the various settings.

·         The first table gives information about several registry settings that are recommended and/or frequently used to improve FSSP’s performance.

·         The second table gives information about registry settings related to blocking unwanted files.

·         The third table gives information about registry settings used to set file size limits.

·         The fourth table gives information about registry settings used to control the actions FSSP takes when infected files are detected.

Please Note: You should only make changes to registry settings if you are comfortable working in the registry. If you are uncertain, you should open a support case for assistance.

Recommended settings to maximize performance

Settings used to block unwanted files

This section details the various settings that FSSP uses to block specific files.  This section is provided as a quick reference on how to configure FSSP to bypass these settings in the event of unexpected behavior.  It is not recommended that you make any changes to these settings unless you are experiencing a particular problem that is leading to detections that you think are in error.

Settings used to configure file size limits

Currently there is no way to set FSSP to skip these limit checks, but the limits can be increased if necessary.  If a file exceeds these limits, then the file will be blocked.

Settings used to control how FSSP behaves when updating infected files

These settings control the action FSSP takes for large infected container files and exceedingly nested container files.

Forefront and Memory usage

Another important consideration when evaluating the performance of your SharePoint servers running FSSP is the impact of the antivirus scanning engines. Forefront utilizes many third-party virus scanning engines and components to provide virus and keyword filtering of the SharePoint server.  The Forefront team has automated backend systems that are constantly stressing these 3^rd party components to ensure that they are behaving correctly and utilizing memory as efficiently as possible.  There have been incidents in the past, however, where a memory leak has been introduced through the update of one of our third-party engines.  We are continually improving our back end tests to be able to detect these memory leaks before they are published.

If FSSP is unable to allocate memory while scanning a file, it currently does not differentiate between a large memory allocation that failed (because it is just too big) vs. a small allocation that failed (because a leak has consumed all usable memory).   Depending on the type of file being scanned, and where in the scanning the memory allocation failure occurs, FSSP may report the problem as a “corrupted compressed” file, as an engine error, or as a scanning process exception.

A new feature has been added to FSSP SP3 to provide an additional layer of protection in the event a third-party vendor releases an update with a leak that is not detected by our back-end testing.  The new feature is to periodically recycle the FSSP scanning processes in a controlled manner.  This new registry key (named RecycleSPScanJobs) limits the life of our scanning processes to a finite time.  By recycling the FSSP scanning processes, any leaked memory is recovered, thus reducing the probability of encountering a memory allocation failure.  This feature will sequentially restart one scanning processes at a time, and the scanning load is shared among the other scanning processes during the recycle.  We recommend setting this new registry key to 96 hours. 

The registry key is a DWORD named “RecycleSPScanJobs” and is specified in seconds.  To set this value to 96 hours, you will need to create the key and enter a value of 345,600 (which is 60 seconds * 60 minutes * 24 hours * 4 days).  This will cause Forefront to reset its scanning processes every 4 days.

John Oesterle  
Senior Development Lead

Michel LaFantano           
Senior Writer - BPSG iX

If you are managing multiple SharePoint servers with Forefront Protection 2010 for SharePoint (FPSP) installed and would like to share your FPSP configuration settings among your various installations, you can use PowerShell to export the settings from one configured instance of FPSP and then import the settings into other instances of FPSP.

Micah LaNasa, a tech writer on the BPSG iX team, recently posted a video that takes you through the process step-by-step. You can find the export/import video here:

 http://edge.technet.com/Media/Importing-Configuration-Settings-in-Forefront-Protection-2010-for-SharePoint/

You can find the export/import documentation in the TechNet library here:

http://technet.microsoft.com/en-us/library/dd639448.aspx

I hope you find both the video and the documentation helpful.

Michel LaFantano

BPSG iX

There are some great opportunities coming up this month to learn about Forefront solutions.

TechNet Simulcast: Forefront Virtual Event
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032454002&Culture=en-US

Register for the Forefront Virtual event on June 23^rd and 24^th to hear from the product team, ask questions and see great technical demos on FEP, FIM, TMG, UAG, FPSP, FPE, FOPE, and ADRMS + Exchange.

Deployment Webcasts

6/28/2010 11:00:00 AM -Deploying a Microsoft Identity and Access Management Solution (Level 300)

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032453697&Culture=en-US

6/30/2010 8:00AM Best Practices for Deploying a Microsoft Secure Collaboration Solution (Level 300)

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032453700&Culture=en-US

6/22/2010 12:00PM Using a Microsoft Information Protection Solution with RSA Data Loss Prevention

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032453692&Culture=en-US

6/22/2010 9:00:00 AM - TechNet Webcast: Deployment Best Practices for Information Protection

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032453503&Culture=en-US

6/16/2010 10:00:00 AM - Enabling Secure Messaging – FOPE Deployment Best Practices

https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032450259&EventCategory=4&culture=en-US&CountryCode=US

Tomorrow at 2:30 pm Eastern time, tune in via Twitter to see Kelly Higgins of Dark Reading interview  JG Chirapuarth, senior director of the Microsoft Identity and Security Business Group.  You can follow the discussion at either the Dark Reading or Forefront Twitter Account.

Today we released Forefront Protection 2010 for SharePoint and Active Directory Federation Services 2.0, which makes it a good time to talk about secure business collaboration.

It is clear that collaboration drives the modern enterprise.  Sharing documents and applications within the company, from the remote office, with trusted partners and customers, into the cloud, etc. – is crucial for most organizations today.

Collaboration is a key engine for success, regardless of which industry or part of the world you’re in.  And, whether its deployed on-premises or as hosted cloud service, the new SharePoint 2010 is the ideal business collaboration platform to connect people within the enterprise and beyond. 

Of course, ensuring valuable information is safe against accidental loss, theft and malicious software is no trivial exercise in the world of cloud computing and cross-company collaboration.  Information is the lifeblood of any organization and it must be secured.  In his blog Gartner vice president Neil MacDonald wrote about this “tearing down of walls between businesses and the opening up of our information, processes and systems to outside parties – whether these are contractors, outsourcers, partners and customers. Nearly every enterprise I speak with is being asked to enable and foster secure collaboration with external entities.”

Working with customers and partners, Microsoft has learned a great deal about secure collaboration.  Based on this, we thought we would share our top five recommendations to help companies strike the right balance of risk management and productive collaboration. 

·         Be a Team Player:  Build a virtual team across security, content, identity and business managers for a holistic approach.

·         Strive for Defense-in-Depth:  Apply strong anti-malware on SharePoint, in addition to anti-malware on PCs and servers.

·         Extend the Power of Identity:  Identity is at the center of good security.  Apply interoperable technologies to manage and federate identities across company boundaries and into the cloud (e.g. Single Sign-On.)

·         Go the Extra Mile to Protect Your Information Lifeblood:  Use rights management policies and technology to keep sensitive content out of the wrong hands.

·         Be Cloud-Ready:  Investigate your cloud vendor’s security measures.  Choose technologies that bridge in-house and cloud systems.

The new Forefront Protection 2010 for SharePoint and Active Directory Federation Services 2.0 (ADFS 2.0) provide essential building blocks for a Secure Collaboration solution.  They also represent great progress for what we call our Business Ready Security strategy to help enterprise customers manage risk and enable productivity. 

Forefront Protection 2010 for SharePoint is deeply integrated with SharePoint Server 2010, preventing employees from uploading or downloading infected docs, inappropriate content, or sensitive information. 

Active Directory Federation Services 2.0 is a no-cost download for Windows Server.  It enables easier, more secure access to applications on-premises and in the cloud, as well as collaboration within the enterprise and across organizational boundaries.  ADFS 2.0 lets companies apply their existing on-premises identities to the cloud. 

Learn more here.

If you are in San Francisco at the RSA Conference, be sure to visit the Microsoft booth (#1517) for these 20 minute theatre presentations:

Wednesday:

Better Together:  Exchange Server 2010 and the MS Forefront Secure Messaging solution:  12:40 pm

Securely Collaborate with Partners and Employees Using SharePoint and Business Ready Security from MS Forefront:  1:40 pm

Protecting Endpoint from Advanced Threats with MSFT's Secure Endpoint Solution:  4:10 pm

Thursday:

Microsoft Identity and Access Management Solution:  11:40

With the new 10.1 version of Forefront Online Protection for Exchange (FOPE) customers can submit technical support requests directly from the FOPE Admin Center site.

Support requests are typically responded to in less than 24 hours, depending on severity level.  For details, see the New Features Guide and the 10.1 Admin Center Guide.

Customers have three ways of contacting support:

1.      A “Get Help Now” link to the Microsoft Support request site now appears in the Administration Center on both the “Resources” page and the shortcut menu underneath authorized users’ logon names.

·        This link will lead to the Microsoft Support home page. Here, authorized users can complete and submit support requests.

·        Customers can also track the progress of all submitted support requests through “View Incidents” Link.

2.      Telephone: For emergency or urgent support requests requiring faster turnaround. In the United States and Canada, call toll-free (866) 291-7726 or dial direct (204) 927-2299. Outside the United States, call the Universal International Free phone Number 800-0000-0060. Additional international support phone numbers are listed in the Resources tab of the administrative console.

3.      Microsoft Premier Support:  This service is for Microsoft Premier Support subscribers only and the process remains unchanged for premier customers. For more information about accessing Premier Support, go to the Microsoft https://premier.microsoft.com .”

This week we released an update to Forefront Online Protection for Exchange (FOPE) - our hosted service providing anti-malware and anti-spam for both on-premises Exchange and Exchange Online.  FOPE can be used as an alternative to the new Forefront Protection 2010 for Exchange Server, or in tandem with it for messaging defense-in-depth.

The new release of Forefront Online Protection for Exchange offers enhanced policy control capabilities (such as enhanced regular expressions support, custom dictionaries) for IT admins to more effectively adhere to compliance needs.  In addition, it supports advanced globalization/localization by supporting 13 languages in the Admin Console, in documentation and via telephone support. These enhancements were a direct result of feedback from Forefront Online Protection for Exchange customers, who expressed a need for more options when they created custom company policy rules for filtering, and more flexibility to manage these rules.

Additional enhancements with the new release:       

·         Policy rule syntax options: The new release provides the option to use either a basic syntax, which is a mixture of comma-separated values (CSV) and simple string-wildcard syntax or Regular Expressions.

·         New Policy Rules e-mail header match option: FOPE now allows you to match e-mails based on e-mail header name and value.

·         More flexibility for outbound forced TLS rules: The Policy Rules editor now offers a check box to enable Opportunistic TLS for recipients not specifically identified by the policy rule.  Custom policy rules filters now feature the following enhancements:

The ability to upload dictionaries of custom-created lists or content for use in policy rules

The ability to apply the dictionaries across multiple rules and domains

 

Today at the TechEd Europe conference, in conjunction with the launch of Exchange Server 2010, Microsoft launched Forefront Protection 2010 for Exchange Server.  The product and evaluation software is available now.

Part of our Business Ready Security strategy, Forefront Protection for Exchange (FPE) offers multiple anti-malware engines for 38 times faster detection than single engine solutions, and 99% guaranteed spam protection with only one in 250,000 spam false positives.  Customers also have the choice of using the hosted Forefront Online Protection for Exchange service, or both offerings together for defense-in-depth.

Like all of our Forefront solutions, FPE is designed to help companies balance the needs of business with security requirements.  Email is an extremely critical application, of course, and it presents challenges to both businesspeople and IT managers.  Employees (and non-employees) needs secure access to messaging and documents from anywhere, as well as a spam-free inbox and protection from malware.  On the other hand, IT must manage multiple sites and devices, ensure information protection and compliance, and ward off financially-motivated threats.

Combined with Exchange 2010 and other Microsoft identity and security technologies, FPE is part of Microsoft’s comprehensive solution for secure messaging.  (It’s worth watching a video presentation on the whole solution here, in fact.)

Over on TechNet Edge Mike Chan, product manager for the Forefront team, breaks down the differences between security protection for Forefront Protection for Exchange (FPE), Forefront Online Protection for Exchange (FOPE), and the built-in protection which exists in Exchange 2010.  We start out with a brief history of the messaging products and then dig into the details of differences between FPE, FOPE, and Exchange 2010 on the whiteboard at [4:22].  Should you run FPE alone or FPE and FOPE?  Watch and decide.

Watch the video here:  http://edge.technet.com/Media/FPE-vs-FOPE-and-Exchange-2010--Secure-messaging-with-Forefront/ 

If you're not already aware...the Release Candidate of Forefront Protection 2010 for Exchange Server (the next, newly named version of Forefront Security for Exchange) is available for download and evaluation now!  Part of the Forefront Protection Suite - the next generation of the Forefront Security Suite, aka "Stirling" - FPE provides fast and effective protection against malware and spam by inlcuding multiple scanning engines. Its comprehensive messaging protection also prevents out-of-policy content from entering or leaving your network using content filtering. And it integrates with Forefront Online Protection for Exchange to provide the defense-in-depth benefits of hosted and on-premise filtering in a single solution.

Many companies and IT leaders are eager to realize the benefits of cloud computing, but security is often a concern.  For example, a recent study by Maritz Research found that 59% of IT leaders in the US rated security as the biggest risk with cloud. 

As part of our Business Ready Security strategy , we are taking a comprehensive approach to security across on-site and cloud infrastructure.   This encompasses protection, access and management, all built around user identity and integrated with a highly secure, interoperable platform for a broad set of partner solutions.  (At the Worldwide Partner Conference on 7/13, we also announced the official names of the products comprising the Forefront Protection Suite, previously known as codename “Stirling”, in an effort to align our portfolio with this broader definition of security.)

We are delivering both standalone security services and security technologies within Microsoft’s cloud infrastructure.  Forefront Online Protection for Exchange is an example of a standalone service solution, providing email security for both on premise Exchange Server and Exchange Online (and other on-premise messaging systems.)  Another example is System Center Online Desktop Manager, available in beta by the end of the year.  It is an integrated security and management tool that will provide desktop management capabilities in the form of an online service.

Identity is a core part of our strategy, because it allows for more contextual protection and access to information and resources.   With our Forefront platform, on-premise identities, such as those in Active Directory, work with cloud services.  That enables simplified, secure user access to applications, such as Exchange, regardless of where the application is hosted.  

Forefront's identity provisioning/de-provisioning and access management empower customers to integrate their investments in Active Directory and existing identities with cloud infrastructure.  And, with solutions like Rights Management Services, in the future customers will be able to enforce persistent, identity-based policies around data anywhere it is stored, sent, or accessed - including the cloud.

We are also providing fundamental identity components for Microsoft cloud services, such as the Azure Services Platform.  The Microsoft Services Connector, for example, extends identities from on premises systems to cloud services.  The .Net Access Control Service issues and manages identity “claims.”  Both are based on the next generation of Active Directory Federation Services, Windows Cardspace, and Windows Identity Foundation which comprise an open platform for simplified user access that works across organization boundaries for on-premise and cloud-based applications.   Beta 2 of all three components is currently available.

Today, we released a new version of Forefront Online Security for Exchange (Release 9.1). This release delivers key enhancements to the directory synchronization tool as well as usability improvements to the administration center and spam quarantine.

New features in this release include:

• Enhanced Directory Synchronization Tool (with Differential Sync)
• New Track Changes Option
• Domain Enhancements
• New Blind Copy Option for Outbound Suspicious E-mail
• One- Day Interval for Spam Quarantine Notification Settings      
• Enhanced Reporting Features   
• Scheduled Reports sent by E-mail
• New Outbound Suspicious Traffic Type 
• Top User Reports
• Reporting Web Service for Forefront customers
• Enhanced Audit Trail Search       
• Date Range        
• Bulk Uploaded User Events

To see a demo of some of these features - check out our TechNet Webcast on FOSE here!

More than 97% of all email is spam!  And it is more than annoying…it also creates the ideal environment for malware attacks and phishing attempts. In response, we have recently launched the Forefront Anti-Spam Resource Center.  Visit the site and add it to your favorites to stay up to date on Microsoft’s products, technologies and research to help you mitigate the risks and annoyances of spam in your company.

Below is an interesting graphic on the most common spam topics.

Related to this:  Don’t miss this upcoming TechNet Webcast: How Microsoft IT uses the Exchange Hosted Services to Protect the Messaging Environment