MS09-056 addresses two vulnerabilities that affect how the Windows CryptoAPI parses X.509 digital certificates. Applications on the Windows platform as well as Windows components such as the WinHTTP API can call into the CryptoAPI which provides cryptographic services to validate digital certificates. Internet Explorer, for instance, uses the CryptoAPI to parse and validate the certificate of remote web servers while browsing.

Digital certificates can prove that one peer in an SSL connection is who he claims to be. They are signed by a trusted, independent third party known as a Certificate Authority. Most often used to protect communications to web sites, they are also in common use to protect e-mail communications or B2B connections. The X.509 standard describes what information can go into a certificate and uses ASN.1 (Abstract Syntax Notation 1) to describe the format of the data. Object Identifier or OID  is the ASN.1 type used to identify specific elements of the certificate such as an algorithm or attribute type. For example “2.5.4.3” is the OID that identifies the “Common Name” or “CN” string field in a certificate. 

Addressed in this security update are a null truncation vulnerability and an integer overflow condition in ASN.1 parsing. Both of these vulnerabilities were discovered and presented by Dan Kaminsky at the BlackHat security conference in Vegas at the end of July of this year.

·         CVE-2009-2510: Fields in the certificate’s subject name (such as the ‘Common Name’ or ‘CN’ field) which contains a NULL character in the string will cause the CryptoAPI to parse only the portion of the string prior to the NULL character. However, the certificate may have been issued to the organization / domain that comes after NULL character in the string.

·         CVE-2009-2511: In a certificate, each Object Identifier (OID)  is stored as a sequence of integers but is converted to a string by CryptoAPI when parsing a certificate. .  The ASN.1 standard does not specify a maximum value for integers, but CryptoAPI assumes integer components of an OID can be safely parsed into a 32 bit integer in memory. A specially crafted OID number may result in an integer overflow condition that could cause it to be parsed in a way that allows the OID number’s data to replace the data for the previously encountered OID.  This can cause the Certificate Authority and Windows to parse the certificate differently. This vulnerability can be exploited in those cases where the Certificate Authority ignores the specially crafted OID and agrees to sign the certificate, whereas the Windows CryptoAPI does parse the crafted OID.

Both of these vulnerabilities have an impact of spoofing, which means that an attacker could use them to fraudulently spoof the identity of another legitimate server on the internet.

This sounds quite serious and it is. However, it is important to take into account that the effort required in setting up such an attack is extensive. In order to exploit this issue in a web browsing scenario an attacker must successfully complete the following steps:

1.     Convince a certificate authority to sign a rogue certificate. This would need to be a Certificate Authority that is present in the Root Certificate store of the Windows machine;

2.     Execute a successful man-in-the-middle attack that hijacks the connection from a vulnerable client to a server and present the certificate to the client, e.g. via a DNS spoofing attack or  via ARP cache poisoning on a local subnet.

Leveraging an attack which abuses these flaws is not trivial but cannot be excluded. We do believe that the threat of these attacks is significantly mitigated by these requirements posed on the attacker. However, the TLS Handshake Protocol (RFC 2246) makes two security promises that are violated by these vulnerabilities:

·         The peer's identity can be authenticated;

·         That no attacker can modify the communication without being detected by the parties to the communication.

As this vulnerability shows the potential of breaking this security promise, we consider it important to address these issues and are releasing this security update. We recommend that customers install them at their earliest convenience.

Updates to the CryptoAPI affect a vast number of applications that run on the Windows platform and these require very thorough and stringent testing prior to release. For this specific update our engineers looked specifically for applications that may have been affected by the unique changes made to this API and performed very detailed and specific interoperability testing. Quality of security updates is paramount to Microsoft which for the CryptoAPI often results in a fairly long test cycle.

During the development of these security updates Microsoft has continued to evaluate the threat environment to assess the risk these vulnerabilities posed to our customers. Certificate authorities that are included in the Root Certificate store on Windows are all required to meet the requirements of the Microsoft Root Certificate Program. A list of the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Root Certificate Program can be found in KB article 931125. During the development of these updates the MSRC has worked with certificate authorities to ensure that their systems were also hardened to help prevent signing certificates that may have attempted to exploit these vulnerabilities.

Thanks to Gavin Thomas and Robert Hensing from the MSRC Engineering team and Kelvin Yiu from Windows Crypto for their technical investigation into these two issues.

-Maarten Van Horenbeeck, MSRC Program Manager

MS13-051 addresses a security vulnerability in Microsoft Office 2003 and Office for Mac. Newer versions of Microsoft Office for Windows are not affected by this vulnerability, but the newest version of Office for Mac (2011) is affected. We have seen this vulnerability exploited in targeted 0day attacks in the wild. In this blog we’ll cover the following aspects:

• Technical Details
• Attack Pattern
• Advice for Detection

Technical Details

In the Office PNG file parsing code, there is a vulnerability where the length field of a chunk is not correctly checked. The PNG specification (http://www.w3.org/TR/PNG/#5Chunk-layout) says “Although encoders and decoders should treat the length as unsigned, its value shall not exceed 2^31-1 bytes.” However, in the malicious PNG files, we found the length field of a chunk equal to 0xFFFFFFFF. The PNG parsing code correctly treated this field as unsigned (as specified in the PNG spec), but was not catching the case when the value was 0xFFFFFFFF, which if interpreted as an unsigned value, exceeds 2^31-1. Below is what the malicious chunk size looks like (highlighted in yellow):

Shellcode analysis shows that the exploit for this vulnerability was a classic stack based buffer overflow, which wrote far past the end of a buffer on the stack, thereby overwriting control data on the program’s stack, eventually leading to high-jacking the program’s execution. Older versions of Office/Windows don’t have mitigations for these types of exploits, but newer versions of Office/Windows do. This is an example of how running current software can increase an organization’s security. We verified also that EMET 3.0 (and above) is able to stop the exploits observed so far, providing an additional mitigation against this specific attack.

Attack Pattern

The attacks we observed were extremely targeted in nature and were designed to avoid being investigated by security researchers. The malicious samples observed are Office documents (Office 2003 binary format) which do not include the malicious PNG file embedded directly in the document. Rather, the documents reference a malicious PNG file loaded from Internet and hosted on a remote server.

Attackers also equipped their servers with scripts which avoid serving the PNG exploit multiple times, in an effort to keep this 0day more concealed. We believe that the limited attacks observed were geographically located mostly in Indonesia and Malaysia.

Advice for Detection

The common pattern for all these documents is the filename “space.gif” used by each malicious file to fetch the remote PNG file containing the exploit. In order to help security vendors and enterprises look for potential indicators and to deliver an effective protection, we are providing some of the URLs used to load the remote PNG exploit and hashes of the malicious Office binary format documents observed in these limited targeted attacks.

hXXp://intent.nofrillspace.com/users/web11_focus/4307/space.gif
hXXp://intent.nofrillspace.com/users/web11_focus/3807/space.gif
hXXp://mister.nofrillspace.com/users/web8_dice/3791/space.gif
hXXp://mister.nofrillspace.com/users/web8_dice/4226/space.gif
hXXp://www.bridginglinks.com/somebody/4698/space.gif
hXXp://www.police28122011.0fees.net/pages/013/space.gif
hXXp://zhongguoren.hostoi.com/news/space.gif

Thanks to Andrew Lyons and Neel Mehta of Google Inc for the report, and to Elia Florio and Cristian Craioveanu for helping with this case.

- Neil Sikka, MSRC Engineering
@neilsikka

Today we released seventeen security bulletins.  Two have a maximum severity rating of Critical, fourteen have a maximum severity rating of Important, and one has a maximum severity rating of Moderate.  We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Thanks to the whole MSRC Engineering for their work on this month’s cases.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Bulletin severity is an interesting topic to many blog readers.  We often hear that you think a bulletin should be rated higher or lower.  Sometimes we even hear one person suggesting a higher rating and another suggesting a lower rating for the same issue.  J  This post is not to advocate for or against the MSRC rating system but we’d just like you to understand what we were thinking for each bulletin.  Our official bug bar is not posted but we pointed to a close approximation of it last month in this blog post (http://blogs.technet.com/swi/archive/2008/09/09/ms08-055-microsoft-security-response-process-behind-the-scenes.aspx).  Direct link is http://msdn.microsoft.com/en-us/library/cc307404.aspx if you want to follow along.

MS08-057 fixes several Excel vulnerabilities reachable by opening a malformed Excel spreadsheet. This vulnerability is rated Critical for users of Office 2000 because some configurations of Office 2000 do not prompt before opening an XLS file offered via a website.  It is rated Important on the other affected platforms where Excel does display the Open/Save dialog prompt before opening.  This user interaction (clicking through the prompt) lowers the code execution vulnerability from Critical to Important.

MS08-058 addresses six separate CVE’s in Internet Explorer.  They can be lumped together into three different buckets.

The first three IE issues each allow cross-domain script execution.  On Windows 2000, a webpage that can execute script in the local machine zone can run arbitrary code.  So that’s a Critical “Remote Code Execution” class vulnerability on Windows 2000.  All other platforms have a feature called “Local Machine Zone Lockdown”.  With LMZ-L enabled, attackers can no longer run script in the local machine zone so there is no direct remote code execution opportunity.  Instead, the risk is Information Disclosure as malicious.com can trick you into posting website cookies for another domain.  Windows Server 2003 and 2008 have both the local machine zone lockdown feature and have enabled the Enhanced Security Configuration by default.  ESC disables scripting.  Without script, cross-domain scripting is not relevant.  If users disabled ESC, this would be an information disclosure threat.  However, because the attack surface is not exposed by default, we drop it down two ratings from “Important” to “Low”.  Each of these three issues are different vulnerabilities.  With CVE-2008-2947, an attacker can force script to execute in the wrong domain context by playing tricks with the location object.  CVE-2008-3472 and CVE-2008-3473 confuse IE into executing script from a different zone through mouse and focus trickery.

The next vulnerability in the list, CVE-2008-3474, is also a cross domain vulnerability but you probably noticed that this is not rated as a Remote Code Execution Critical vulnerability on Windows 2000. This is a case of malicious.com being allowed to make requests via MSXML from other zones. However, in this case, malicious.com cannot trigger the vulnerability without some help. In fact, to trigger this vulnerability, a victim page must host the malicious page in a frame. The “Important” rating we gave it might be a little bit of a stretch but the advertising hosting model of untrusted content being hosted on trusted pages tipped us over to rating this one Important. Again, the Enhanced Security Configuration on Windows Server 2003 and 2008 mitigates this threat so it is rated two notches lower on those platforms.

Finally, the last two CVE’s are straight memory corruption issues.  CVE-2008-3475 fixes an issue where a pointer is uninitialized and then used.  CVE-2008-3476 addresses a case of script methods being called out of order in an unexpected manner.   Neither of the issues affects Windows Vista but on Windows 2000 and Windows XP they could result in code execution, “drive-by” class vulnerabilities.  Scripting is disabled by default on Windows Server 2003 and 2008 so the memory corruption issues that require scripting on those platforms drop down two severity notches to “Moderate”.

MS08-059 addresses a vulnerability in the Host Integration Server RPC service.  One of our team members wrote a great blog post about it [here].

MS08-060 addresses a remote code execution vulnerability on Windows 2000 domain controllers.  We have rated the bulletin Critical.

MS08-061 fixes three different win32k.sys (kernel-mode) vulnerabilities involving privilege escalation from an unprivileged local user to ring 0.  Fermin wrote more detail about it [here].

MS08-062 addresses a vulnerability for which we have seen targeted attacks so we’re very happy to be getting it fixed.  This fixes an issue with the Internet Printing Service, an IIS ISAPI filter that requires authentication in order to reach.  Remote authenticated code execution vulnerabilities rate Important according to the bug bar.

MS08-063 is remote code execution vulnerability reachable over SMB.  However, an attacker cannot reach the vulnerable code using the null session share so the attacker must be authenticated to exploit this vulnerability.  (or the Guest account must be enabled)  Again, we rate remote authenticated code execution vulnerabilities as “Important”.

MS08-064 addresses a vulnerability that could allow a local attacker who has logged onto a system to potentially execute code in ring 0.  Local elevation of privilege vulnerabilities are rated Important.

MS08-065 is rated Important and two team members wrote a blog post that explains it in more detail.  You can read that [here].

MS08-066 is another local elevation of privilege vulnerability.  It allows a 16-byte memory overwrite to an arbitrary location to local attackers so this one is rated Important.  Fermin wrote more about this vulnerability [here].

Finally, we also released a security advisory with killbits for several controls.  Releasing killbits via security advisory is something relatively new from Microsoft.  There are two scenarios where we will release a killbit via security advisory instead of a security bulletin.  First, when a Microsoft  control has already been fixed with a previous security bulletin, we will follow on later with a killbit package.  The other scenario is when we issue killbits for 3^rd party products.

Thanks for reading and we hope this gave you a better understanding of the Microsoft bulletin rating system.  Please email us with any questions.  Thanks!

Update 10/16/2008 - Fixed formatting.  Thanks Frank for pointing it out!

- Jonathan Ness, SVRD Blogger

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

Microsoft Host Integration Server 2006 is an interesting product.  It allows developers to manage business processes on IBM mainframe and AS/400 (big iron) servers as XML web services.  You can find a free trial version available for download at http://www.microsoft.com/hiserver/downloads/default.mspx.

Unfortunately, access to the management interface was not properly locked-down.  MS08-059 is an update for Microsoft Host Integration Server 2006 which secures the SNA RPC service interface.  It is possible for an attacker to run code remotely and take control of a Microsoft Host Integration Server 2006 if this update is not installed.  The update adds better RPC user verification as well as locking down some of the unneeded remote management functionality exposed by this interface.

If you use Microsoft’s Host Integration Server 2006 in your environment, it’s important that you secure the servers running HIS as soon as possible.  Our first recommendation, of course, is to apply the security update as soon as possible.  If you cannot apply the update right away (it does require a reboot), there are a couple things you can do to limit your exposure to any potential attacks abusing this vulnerability.

One temporary workaround is to use the Service Control Manager to disable the SNA RPC service, and prevent it from starting automatically.  This will prevent the vulnerable service from running, but will also prevent remote management.  Firewalling the RPC port is not a valid workaround, since the port used for communicating is dynamically assigned when the service starts.

One thing you could do to limit risk is to run the service as a lower-privileged user.  Any successful attacks would then run at a reduced privilege, hopefully limiting the extent of the damage.  We already recommend this during installation by displaying a pop-up warning (see screenshot below).  We also mention this in documentation, but some people might have missed that so we’re emphasizing this option in this blog post.  Running under a non-administrator account reduces potential risks and will limit exposure of the vulnerable interface.

- SVRD Bloggers

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

This month we shipped a security update and bulletin (ms10-105) to address vulnerabilities in the .cgm, .tif, .fpx, and .pct image filters.  These filters are shipped with Microsoft Office to extend image rendering for applications.  Neither Office 2010 nor Office 2007 use filters to perform rendering by default.  Both use GDI+ instead.  Historically, if an image filter was incapable of rendering an image and GDI+ supported the image format, GDI+ would be asked to render the image.  GDI+ worked as a backup renderer.  The newer versions of Office have switched to using GDI+ as the default render and have also deprecated the use of some filters.

What the update does

The update will include an updated version of .pct filter to address a vulnerability found in that filter.  In addition to that the update makes GDI+ the default renderer on versions of Office prior to 2007 (as opposed to using the filters that ship with Office).  Beyond this, a filter allow-list was backported from Office 2010 and Office 2007 to downlevel versions of Office.  The  allow-list enables commonly used filters and disables other legacy filters.  However, if needed administrators can re-enable the legacy filters through a registry key.

Registry Location: HKLM\software\microsoft\office\common\security\allowlists\graphicsfilterimport
Name: AllowListEnabled
Type: DWORD
Description: This registry key controls whether an allow-listshould be used for image filters. If this registry key is set to 1, Office will look at other keys in the same registry location for filters to enable.  The filters to enable are specified by creating a new string value for each filter with a name of FILTER.FLT (where FILTER.FLT is the name of a real filter) and a value of the format XX.YY.ZZ.WW (where XX, YY, ZZ and WW specify the version of the filter).
Values:

• Key not present (default)
  After the update has been installed, all versions of Office will default to routing GIF, PNG, JPG and BMP through GDI+. The PICT and EPS filters will be enabled.  All other filters will be disabled

• Set to 1
  If the registry value is set to 1, it tells Office to use an allow-list based on the filters explicitly specified in the registry. If this value is set in the group policy hive then Office assumes the system administrator wants to control the filters and does not read any filter data from the machine hive.

• Set to 0
  If the registry key is set to 0, all filters are enabled.

MS08-050 concerns an ActiveX control that can be maliciously scripted to leak out personal information such as email addresses.

There appeared to be no need for the control to have this behaviour so giving it a Kill-Bit seemed the correct approach to take. During the extensive testing that each security update undergoes, however, it became apparent that the Kill-Bit wasn’t ideal as it partially broke the Remote Assistance application.

So how do we kill off a control, keep the Remote Assistance functionality and still protect our customers?

Firstly the original control must receive a Kill-Bit to prevent the control being foisted on to users.

Secondly the control was modified so that when it initializes it first checks to see what process it’s running within. If the process attempting to invoke the control is Remote Assistance (1) or if the caller is in a white list of applications found in the registry (2), then the control is permitted to be loaded. Otherwise it will not load.

Finally we issue a Phoenix-Bit (AlternateCLSID) so that Remote Assistance can continue to use the old ClassID.

1 "%SystemRoot%\pchealth\helpctr\binaries\helpctr.exe"

2 "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\ImageName\” Where ImageName is the name of the executable that is to be added to the list (e.g. foo.exe), has the value "AllowMessengerExecHandleFailure" of type DWORD and the data set to 1

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

We are pleased to announce that as of today customers with access to Microsoft Services Premier and Professional Support can receive EMET related technical assistance. This is an important step for us to better support professional and enterprise customers and answer questions related to EMET deployment, configuration, and troubleshooting. The support will be fee based. Also, while there is support for EMET, servicing is done via version releases and there will be no hotfix support.

The EMET 3.0 is currently the only version offered support through Microsoft Services Support channels.

As we have since its inception, we will continue to provide support through Technet forums (http://social.technet.microsoft.com/Forums/en/emet/threads) for version 2.1 of EMET, as well as for consumers and all those who do not have a Premier or Professional contracts.

Remember to also visit our TechNet page where you can find the latest articles, downloads and news related to EMET at the page www.microsoft.com/emet.

- Gerardo Di Giacomo, MSRC

Today, we released MS09-023, a bulletin for Windows Search 4.0. It is an information disclosure vulnerability rated as Moderate. We would like to go into more details in this blog to help you understand:

• What is the attack vector?
• Why is this vulnerability rated as Moderate?
• What is the risk of MSHTML hosting apps?

What is the attack vector?

The vulnerability in Windows Search allows script in HTML files to be executed without a prompt.

A typical attack scenario would be as follows:

• The attacker puts a specially crafted HTML file on your system or in an e-mail message in an indexed mail box.
• The user performs a search.
• This item is included in the search result list.
• If the item is the first result, it will be automatically previewed, and thus the script within will be executed. Otherwise, the user would need to select and preview the item in order for the script to be executed.

Why is this vulnerability rated as Moderate?

As shown above, significant user interactions are required in order for exploitation to occur. Also, Windows Search is an optional component which is not installed on the default configuration. That’s why we rated this vulnerability as Moderate instead of Important.

What is the risk of MSHTML hosting apps?

Windows Search uses MSHTML, a.k.a. Trident, the Internet Explorer browser rendering engine, for rendering HTML content. While this is a great solution to display rich user interface in an application, it is necessary to understand that MSHTML hosting can raise the attack surface of the hosting application, as illustrated by this vulnerability in Windows Search, if the hosting isn’t done correctly. David Ross has done a wonderful SRD blog about this topic. Please refer to “The MSHTML Host Security FAQ: Part I of II” and “The MSHTML Host Security FAQ: Part II of II” for more details.

- Chengyun, MSRC Engineering

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

Today we released MS10-104 to address vulnerability CVE-2010-3964 in SharePoint 2007 server with an important severity rating. In this blog, we would like to cover some additional details of this vulnerability.

Is my SharePoint server affected by this vulnerability?

There are two types of installations for a SharePoint server: standalone and farm. A standalone installation is used for test/evaluation purposes and cannot be used when creating a SharePoint farm. With a farm installation there are two sub-types: complete and web front end. Servers of both types can be used to form a SharePoint farm.  This is how SharePoint server is intended to be used for production deployment.

The following screen capture shows the server types you can select during SharePoint installation

By default, the vulnerable service, "Office Document Conversions Launcher Service", is disabled in SharePoint farm installations. It is, however, enabled for SharePoint standalone installations. Most likely a SharePoint server in production will be deployed in the farm mode, and thus not vulnerable by default.

You can check whether the "Office Document Conversions Launcher Service" is running on your SharePoint server with the command “sc query dclauncher”. If the service is running, then the SharePoint server is vulnerable.

What is the restricted guest account mitigation?

While the "Office Document Conversions Launcher Service" runs under the localsystem account, the actual document conversion process is launched under a special HYU_<ServerName> account. This is a guest account created by SharePoint server and is used only for document conversion. Thus, even if the attacker manages to get the malicious code runs, the code will run under this guest account.

Would disabling the “Office Document Conversions Load Balancer Service” or blocking TCP port 8093 be good workarounds?

In the bulletin, we list workarounds that involve disabling the "Office Document Conversions Launcher Service" or blocking TCP port 8082. In normal scenarios, the user needs to first retrieve a launcherUri through a different service called the “Office Document Conversions Load Balancer Service” before connecting to the “Office Document Conversions Launcher Service”.  On first look it apears that disabling or blocking access to the load balancer service would also be an effective workaround. However, you should note the launcherUri has a predictable format and could be guessed by an attacker.  They could simply connect to the “Office Document Conversions Launcher Service” directly and reach the vulnerability. Therefore, just disabling “Office Document Conversions Load Balancer Service” or blocking the TCP port 8093, which it runs on, would not stop the vulnerability from being triggered.

How can I know if my server was attacked?

The SharePoint ULS (Unified Logging Service) logs are saved under \Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. You can review all entries with “Microsoft.Office.Server.Convers (0x12CC) 0x1750 Document Conversions           Launcher Service” to check for abnormal document conversion requests.

Acknowledgement

Thanks to Robert Orleth on the SharePoint team and Mark Debenham for their work on this case.

-Chengyun Chu, MSRC Engineering