Inside MSRC: Time to rethink security workarounds

Christopher Budd of the Microsoft Security Response Center recommends implementing one of several security workarounds to ensure a secure infrastructure until this month's most important Windows update can be installed.

This Content Component encountered an error

The August 2006 Microsoft monthly security bulletin release is larger than our typical release and includes updates to Microsoft Windows, Office and Internet Explorer. As I do for larger releases, I want to take this opportunity to call out some of the most important details to help you with risk assessment and deployment planning for this month's releases.

In particular I want to focus on information about two of the Windows updates and two of the Office updates. Finally, I will call out information about deployment for a bulletin involving Outlook Express.

Blocking two ports of call
First and foremost this month we want to draw everyone's attention to MS06-040, "Vulnerability in Server Service Could Allow Remote Code Execution, which is detailed in Microsoft Knowledge Base article 921883. Of all the updates being released this month, administrators should focus on this update first for testing and deployment. We believe that, based on their risk assessment of the technical details in the security bulletin, many customers will decide to expedite testing and deployment of this update.

About Inside MSRC

As part of a special partnership with SearchSecurity.com, Christopher Budd, security program manager for the Microsoft Security Response Center (MSRC), offers an inside look at the process that leads up to "Patch Tuesday" and guidance to help security professionals make the most out of the software giant's security updates.

Also see:
Inside MSRC: Debunking Excel exploits

Inside MSRC: ActiveX change goes permanent

Inside MSRC: Wisdom on Exchange security

MS06-040 addresses a single unchecked vulnerability in the Server Service, which provides remote procedure call (RPC) support, file and print sharing and named pipes support. The unchecked buffer occurs in the processing of network packets in such a way that authentication isn't required. This means that someone seeking to exploit the vulnerability could do so by crafting a specially formed network packet and delivering it anonymously to the target system. Because the Server Service runs in the LocalSystem context (the security context of the operating system), any malicious code executed by the Server Service would run in LocalSystem, giving the malicious code complete control of the system.

In assessing this issue, it is important to note that network traffic processed by the Server Service travels over network ports 139 and 445. As a general best practice we recommend that these ports be blocked at any network perimeter; doing so will mitigate the risk.

For MS06-040, administrators who do not normally review or deploy workaround solutions may want to consider doing so until they have successfully completed their deployments. Workarounds available for this issue focus on blocking delivery of network packets on ports 139 and 445 to vulnerable systems. This can be accomplished through a host-based firewall such as the Internet Connection Firewall. Access to these ports can also be blocked by using Internet Protocol security (IPsec) on vulnerable systems. Finally, TCP/IP filtering can be used to block all unsolicited inbound traffic to a system. You can get more information on IPsec and how to apply filters in Knowledge Base articles 313190 and 813878. For information on how to configure TCP/IP filtering, see Knowledge Base article 309798.

Those using the Internet Connection Firewall and other host-based firewalls should be aware that any exceptions to enable file and print sharing will nullify its effectiveness as a workaround; those exceptions allow traffic to flow through the firewall across ports 139 and 445. The MSRC recommends either revoking that exception or exploring other workarounds such as IPsec or TCP/IP filtering.

Lastly on MS06-040, file and print sharing is not enabled by default on systems that enable the Internet Connection Firewall by default: Windows XP SP2 and Windows Server 2003 SP1. However, if you enable file and print sharing on these systems, an exception is automatically made in the Internet Connection Firewall to support this feature.

The wrong way to disclose vulnerabilities
The other Windows security update that I wanted to address this month is MS06-050, "Vulnerability in Microsoft Windows Hyperlink Object Library Could Allow Remote Code Execution, detailed in Knowledge Base article 920670.

This addresses a vulnerability in the Hyperlink Object Library (hlink.dll), which as a part of the Windows operating system is a collection of application programming interfaces (APIs) for handling hyperlinks that applications can use.

The issues were originally reported to us in a responsible manner as acknowledged in the Security Bulletin. Unfortunately, this vulnerability was also discovered by another researcher and instead of disclosing it in accordance with the guidelines around responsible disclosure, it was publicly disclosed. When that happened, it was presented as a vulnerability in Microsoft Excel.

When we saw the report, we immediately initiated our software security incident response process (SSIRP) and investigated. We soon determined that the original public claims were not correct and that the issue was actually located in hlink.dll. We posted this information in the Microsoft Security Response Center (MSRC) weblog.

The reason this is actually an issue in Microsoft Windows -- as opposed to in Excel as initially claimed -- is because, in the public report, the Excel spreadsheet is utilizing the APIs contained within hlink.dll. In this instance, Excel is a vector to the vulnerability located in hlink.dll.

The security update for MS06-050 updates hlink.dll to address the vulnerability.

PowerPoint attacks still highly targeted
While MS06-050 addresses an issue that was originally -- and erroneously -- publicly reported to affect Microsoft Office, MS06-048 addresses a vulnerability that was correctly publicly reported to affect Microsoft Office, specifically a vulnerability in Microsoft PowerPoint.

MS06-048, "Vulnerability in Microsoft Office Could Allow Remote Code Execution," detailed in Knowledge Base article 922968,addresses an issue we first learned about and made a weblog posting about on July 14, 2006. At that time, we noted that it was used only for very targeted attacks, and our ongoing work with partners in the Microsoft Security Response Alliance (MSRA) indicates that this is still the case.

On Monday, July 17, 2006, we published Microsoft Security Advisory 922970 to share additional details about mitigating factors and workarounds for this issue. Now that we've released MS06-048, which announces the availability of the security update to address these issues, we've updated Microsoft Security Advisory 922970 to point to the security bulletin and are advising customers who followed our guidance in the Security Advisory to move to deploy MS06-048.

On a related note, as with last month's Office updates, MS06-048 is only rated "critical" for PowerPoint 2000. For all other versions of PowerPoint it is rated "important." This is because PowerPoint 2002 and PowerPoint 2003 raise a security dialog box that a user must acknowledge before the PowerPoint file is opened, making more difficult any attempts to exploit this with malformed PowerPoint files.

Addressing a VBA vulnerability
Another bulletin I want to cover today is MS06-047, "Vulnerability in Microsoft Visual Basic for Applications Could Allow Remote Code Execution," detailed in Knowledge Base article 921645. In looking at this one, I want to help you to understand what products are affected and what updates apply to you by explaining a bit more about the technology.

This addresses a vulnerability in Visual Basic for Applications (VBA), which is a development technology. Microsoft VBA is based on Microsoft Visual Basic, but is different and separate from it. This means if you are a Visual Basic developer or are running Visual Basic, this update does not apply to you.

Like Visual Basic, VBA provides an integrated development environment (IDE); however, unlike Visual Basic, VBA is integrated directly into a host application. Microsoft Office is one example of a host application for VBA, but there are others -- including non-Microsoft applications -- that incorporate Microsoft VBA.

The vulnerability addressed in MS06-047 occurs in VBA when the host application passes information to the affected VBA component, vbe6.dll. This is similar to what we saw earlier in hlink.dll: The host application is the vector through which someone tries to maliciously exploit the vulnerability in the underlying component.

Host applications for VBA will provide redistributable copies of vbe6.dll. This means that the update you apply will depend on the specific host application installed. There are separate updates for Office 2000 and Office XP families of products (and note that Office 2003 SP 1 is not affected by this).

If you have other host applications that support VBA, you will want to apply the update associated with Knowledge Base article 923167 in the bulletin. If you are a software developer or vendor developing VBA applications, then you will also want to apply the security update associated with 923167. Also note that if you have host applications in addition to Microsoft Office 2000 or Microsoft Office XP, you will want to apply both the update for Microsoft Office and the update associated with 923167.

MBSA 1.2 issue affects Outlook Express Finally for this month, I want to note that MS06-043, "Vulnerability in Microsoft Windows Could Allow Remote Code Execution," detailed in Knowledge Base article 920214, addresses a vulnerability in Microsoft Outlook Express.

While the Microsoft Baseline Security Analyzer (MBSA) 2.0 provides support for Outlook Express, MBSA version 1.2.1 does not. Because of that, we are releasing a June edition of the Enterprise Scan Tool (EST) for MBSA 1.2.1 customers to use for detection.

That covers the important facts about the August 2006 Microsoft monthly security bulletin release. For full details on all the bulletins, please be sure to read the bulletins themselves.

I also want to share with you a final reminder of our monthly TechNet security bulletin webcast, where we will review the bulletins, take your questions and provide answers live on the webcast. This month's webcast will be held Wednesday, Aug. 9, 2006, at 2:00 p.m. eastern. You can register at the URL listed above.

Thank you and have a cool and safe August.

Dig deeper on Security patch management and Windows Patch Tuesday news

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close