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.
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).
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:
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.
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
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.
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
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?
Sharepoint uses Http-Only cookies for authentication. HttpOnly cookies are not accessible through script, significantly mitigating the risk of XSS attacks. For more information, please refer to Mitigating Cross-site Scripting With HTTP-only Cookies.
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.
Or administrators can choose to enable or disable the XSS Filter for any zone via group policy. Please refer to Group Policy and Internet Explorer 8 for more details.
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:
Jonathan Ness, David Ross, and Chengyun Chu, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no