April, 2010

MS10-021 addresses eight different Windows vulnerabilities. Five of them, CVE-2010-0234 through CVE-2010-0238, stem from an obscure bit of Windows registry functionality called “registry links”. A quick search in MSDN reveals this description: “REG_LINK: Specifies a Unicode symbolic link. Used internally. Applications do not use this type”. Clear as mud, right? Registry links are similar to symbolic links in NTFS (http://msdn.microsoft.com/en-us/library/aa365680(VS.85).aspx)). They create a special type of registry key that, when navigated to, redirects the user to another location of the registry.

Examining the affected platforms for each case, it’s evident that the majority of these issues were found and fixed in Vista, due to the extra security work required by the SDL (http://blogs.msdn.com/sdl/). None of the issues affect Windows 7 or Windows Server 2008. Users who have moved beyond Windows XP are better off than others.

Just how bad are these issues? All of them require a logged on local user to trigger. This could be done as a secondary attack after the computer is already compromised or by a malicious user already trusted within the organization. In the grand scheme of all updates released today, these issues may be a lower priority for you to install.

We’d like to salute the finders of this class of attack, Matthew ‘j00ru’ Jurczyk and Gynvael Coldwind, and thank them for reporting these issues responsibly, allowing us to comprehensively address the issues on all platforms. Nice work, guys.

- Nick Finco, MSRC Engineering

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

Today Microsoft released MS10-020, which addresses several vulnerabilities in the Windows SMB client. This blog post provides additional details to help prioritize installation of the update, and understand the attack vectors and mitigations that apply.

Client-side vulnerabilities

The first thing to realize is that this update addresses vulnerabilities in the SMB client in Windows. Typically, machines that act as SMB clients are Windows client machines, not server machines. However, it is possible for a Windows server machine to also act as a SMB client, and depending on the server role and software being used it may be a common scenario. For example: Terminal Server scenarios; logging on to a server as an administrator and accessing files on the network; Servers that mirror content from another SMB server.

It should also be noted that the Browser service, which runs by default on both client and server machines, could be used to facilitate an attack without user interaction. (See http://support.microsoft.com/kb/188001 for more details on the Browser service).

Attack vectors

Unlike server-side vulnerabilities, an attacker cannot simply scan for vulnerable systems and then open connections to attack targets. For an attacker to exploit any of these issues they would have to force a SMB client to make a connection to a malicious server. In general this kind of attack is done in several ways:

E-mail containing links to external web or file servers. (The attacker lures the target into clicking a link and visiting the malicious server.)

Similar to above, but with messages sent via instant-messenger or social-networking services.

HTML e-mail or web-pages containing embedded links to malicious file serves. With some applications, these links may be automatically visited without user interaction.

In all cases, for an attacker on the Internet to be able to exploit these vulnerabilities, the target client machine must be able to make an outbound SMB connection to the malicious server. Firewall best practices recommend blocking outbound (and inbound) SMB traffic (TCP ports 139 and 445) at the perimeter firewall, preventing this attack from succeeding.

That leaves attacks originating from inside the local network (a.k.a. the intranet) – either from a malicious user on the network, or from a compromised machine that is being used as a pivot to reach other targets. In some cases, it may be possible for an attacker on the intranet to hijack legitimate SMB client connections for the purpose of carrying out attacks. As mentioned above, an attacker may cause the Browser service on target computers to make a connection to a malicious SMB server on the local network, potentially without any user interaction.

Mitigations

As explained above, the best mitigation against attacks coming from outside the network perimeter is to block inbound and outbound SMB traffic at the edge firewall. This will prevent attackers on the Internet from being able to lure client machines into connecting to them.

Blocking attacks from the intranet is harder. The best solution is to apply the security update. Other steps that can be taken to reduce risk are to enable SMB signing, so that malicious SMB servers will not be able to establish communication with target clients.

April 13th Update: Added information about the Browser service. We'd like to thank security researcher Laurent Gaffié for helping us clarify the risk.

- Mark Wodrich, MSRC Engineering

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

Today we released eleven security bulletins with security updates addressing 25 CVE’s. Five of the bulletins have at least one CVE rated Critical. We hope that the table below helps you prioritize this month’s deployment.

Victim double-clicks a malicious EXE or allows malicious content to run because content claims to be signed by a trusted publisher.

Critical

2

Likely to see effective proof-of-concept code released to downgrade Authenticode checks from v2 down to v1. Authenticode v1 is a weaker algorithm. To reach code execution, attackers will need to find an Authenticode v1 bypass.

Microsoft Update and Windows Update clients not directly vulnerable to this threat.

Attacker hosts malicious SMB server within enterprise network. Attacker lures victim to click on a link that causes victim to initiate an SMB connection to the malicious SMB server.

Critical

2

Proof-of-concept code already exists for denial-of-service vulnerability. May see unreliable exploit code developed for other client-side SMB vulnerabilities that most often results in denial-of-service.

Egress filtering at most corporations will limit exposure to attacker within enterprise network.

Several issues with differing exploitability. Please see SRD blog for more information.

Attacker spoofs own source address by encapsulating iPv6 attack packet inside IPv4 wrapper. This may allow attacker to reach IPv6 destination that otherwise would be blocked.

Moderate

n/a

May see proof-of-concept released publicly.

There is one additional factor not represented in this table. MS10-019 may be more important to prioritize than it would appear at first glance. User education for years has stressed the need to check the signer or publisher of executable content before allowing it to run. MS10-019 represents an opportunity for attackers to potentially embed malicious content in an executable or executable-equivalent without invalidating the Authenticode-assured publisher. Specifically, the vulnerability allows an attacker to downgrade from strong Authenticode v2 checks to the weaker Authenticode v1 algorithm. The vulnerabilities addressed by MS10-019 will not lead to code execution directly for default installations; however, if you have users making Authenticode-based trust decisions to run content that might have been modified by malicious attackers, MS10-019 should be prioritized higher for your environment.

- Jonathan Ness and Andrew Roths, MSRC Engineering

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

Today we released Security Advisory 983438 informing customers of a cross-site scripting (XSS) vulnerability in SharePoint Server 2007 and SharePoint Services 3.0. Here we would like to give further technical information about this vulnerability.

What is the attack vector?

The advisory states that the vulnerability could allow Elevation of Privilege (EoP) within the SharePoint site itself. We would like to stress that this EoP is not EoP from normal user to admin user in the workstation or the server environment. Instead, the attacker may execute malicious script under a SharePoint user’s context within his/her Sharepoint session. The most likely attack scenario, then, is that an attacker sends a malicious link to a user who is logged into their Sharepoint server. If the user clicks the link, the javascript created by the attacker and embedded in the link would execute in the context of the user who clicked the link.

IE8’s XSS filter is enabled by default in the Internet Zone. The IE8 XSS filter catches this class of XSS attacks so users of IE8 are at the reduced risk from this vulnerability. IE8’s XSS filter is not enabled in the local intranet zone. It can be turned on in the local intranet zone via the following UI.

We recommend a server-side workaround to ACL down the file help.aspx. If you enable this workaround, you will be unable to view Help content within your Sharepoint site. For users who implement the server-side mitigation, help content in English is available here as an alternative to SharePoint-provided help: