Recently, there was a public post in milw0rm (http://www.milw0rm.com/exploits/5530), talking about an issue in the ActiveX control of Microsoft Works 7 WkImgSrv.dll. The PoC claims that it would achieve remote code execution. McAfee Avert Labs Blog also had a post about this (http://www.avertlabs.com/research/blog/index.php/2008/04/17/potential-microsoft-works-activex-0-day-surfaces/).

At first glance the issue sounds serious, right? Upon further investigation, there is no useful attack vector.

The following is the output using the code (ClassId.cs) we posted in another previous SWI blog: Not safe = not dangerous? How to tell if ActiveX vulnerabilities are exploitable in Internet Explorer.

ActiveX Object CLSID: 00E1DB59-6EFD-4CE7-8C0A-2DA3BCAAD9C6

Output:

Clsid: 00E1DB59-6EFD-4CE7-8C0A-2DA3BCAAD9C6

Implements IObjectSafety: False

Safe For Initialization (Registry): False

Safe For Scripting (Registry): False

KillBitted: False

It shows that this ActiveX object is not SFS nor SFI, nor implements IObjectSafety.  

What would happen if we try to load this ActiveX object in Internet Zone?  IE simply would not load it.

Note the zone above shows “Internet”.  This is due to the mitigation introduced in 2005 by MS05-052 in IE.

Here’s the details of what happens in MS05-052, from the previous SWI blog: The Kill-Bit FAQ: Part 2 of 3.

“In MS05-052, IE made a change that affects the way controls are instantiated in the Internet zone. The IObjectSafety check is now frontloaded so that IE can determine control safety status quickly and abort instantiation as soon as a control is identified as unsafe.”

The mitigation introduced in MS05-052 only applies to the Internet Zone. If the object was loaded in the Local Machine Zone (LMZ), IE would instantiate it.  However, any elevation from the Internet Zone to the LMZ would be considered “Zone Elevation” which IE should block and this does not occur on this case. For more details about IE’s zone elevation feature, please refer to http://msdn2.microsoft.com/en-us/library/ms537185(VS.85).aspx. Moreover, IE further protects the user by locking down the Local Machine Zone by default. For more details about LMZ lock down feature, please refer to http://technet.microsoft.com/en-us/library/bb457150.aspx#EHAA.

Now what would happen in Intranet Zone? IE Gold bar pops up to block the use of this ActiveX object in script.  

We would like to clarify that this is not due to the mitigation introduced in MS05-052. Instead, it is related to the following setting.

This morning we released MS08-036 to fix two denial-of-service vulnerabilities in the Windows implementation of the Pragmatic General Multicast (PGM) protocol (RFC 3208).  You probably have never heard of PGM.  Only one engineer on our team had ever heard of it and he previously worked as a tester on the core network components team.  PGM is a multicast transport protocol that guarantees reliable delivery from multiple sources to multiple receivers. It is a layer 4 transport protocol, peer to TCP and UDP.  You can send/receive data with PGM by creating a socket with SOCK_RDM type and IPPROTO_RM protocol.  For example:

s = socket(AF_INET, SOCK_RDM, IPPROTO_RM);

For more information on how to program with PGM, check out the MSDN reference.

The PGM protocol is available on all versions of Windows since XP.  However it is disabled by default on all versions.  We expect that most networks out there will not have a great deal of PGM traffic on it.  Therefore, if you can detect PGM protocol usage on your network and discover a sudden flood of PGM traffic, it’s likely your network is being attacked.  You can detect PGM on the wire by checking the “Protocol” field in the IP header.  PGM’s protocol ID is 113 (0x71).  Both Netmon 3.1 and Wireshark contain PGM parsers.  Here is an example PGM packet capture in Netmon:

P.S. If we’re wrong about the extent of PGM use and there are common applications that use it, please let us know and we’ll revise this blog entry.

- Security Vulnerability Research & Defense Bloggers

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

In some of the multimedia MSRC bulletins that have been released there is a workaround listed about changing ACL’s on Quartz.dll. So, what exactly breaks when we ACL Quartz.dll?

Quartz.dll is a core component of the DirectShow framework. Originally a component of DirectX, DirectShow eventually took on a life of its own as multimedia recording and playback evolved. The DirectShow framework outlines a plug-in model for processing and managing an end to end content pipeline.   Many applications have taken advantage of this pipeline. Some examples include Windows Media Player, Windows Media Encoder, Windows Movie-Maker, Window Media Center, as well as many third party multimedia applications such as video camera applications.

Therefore, after ACLing quartz.dll, applications that count on DirectShow functionality will not work properly. This could include, but is not limited to tasks such as audio/video capture and playback of multiple media types.  For example, in Windows XP,  DirectShow is used for playback of all file types in Windows Media Player.  When Quartz.dll is ACLed, everything breaks: no file can be played back by Windows Media Player.  

Things turn a little bit more complex in Windows Vista. Starting with Windows Vista, the playback experience has been redesigned to take advantage of new OS features. As such, ACL'ing quartz.dll will have the same overall impact as previously mentioned on apps that rely on DirectShow.   However, some apps such as Windows Media Player that can also take advantage of these new OS features may still have some scenarios where content playback will work.

- Security Vulnerability Research & Defense Bloggers

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

This morning we released a critical update for Windows addressing a vulnerability in the Microsoft Bluetooth stack (MS08-030). The bulletin is rated Critical since it allows an attacker to corrupt memory in the Windows kernel, which theoretically could allow an attacker to execute code in the context of the operating system on the remote computer. While we cannot conclusively disprove that attackers will be able to reliably exploit this issue, we still feel it is worth noting the factors which in our opinion make this issue less severe than the bulletin may imply.

First, since the issue is triggered over a Bluetooth link, the attacker would have to be within fairly close physical proximity to the target system. (The standard range of Bluetooth is in the order of meters, although an attacker could use specialized antennas to increase this). This is in contrast to most other remote flaws affecting TCP/IP and related protocols which can be exploited over large distances (e.g. the Internet).

Second, as the security bulletin states, the issue is triggered by a flood of SDP messages. To exploit the issue, an attacker must attempt to trigger a small timing window on the target host. The chances of this succeeding are dependent on the speed of the target, the rate at which SDP packets can be sent from the attacker and received by the target, and the number of processors on the target system. Based on our investigation, a single-processor machine is unlikely to be affected by this issue.

Finally, the attacker needs to find a way to control the memory layout of the target system, and place data they control in the correct location, all within the timing window mentioned above. This is different from other bugs that easily allow an attacker to control the memory layout (think of heap-spraying).

The information above is presented to help customers understand that the “sky is not falling” in terms of immediate risk due to this vulnerability. That said, we still recommend customers patch any affected systems, especially those that have Bluetooth enabled.

- Security Vulnerability Research & Defense Bloggers

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

The MSRC released an advisory today that discusses the recent SQL injection attacks and announces three new tools to help identify and block these types of vulnerabilities. The advisory discusses the new tools, the purpose of each, and the way each complements the others. The goal of this blog post is to help you identify the best tool to use depending on your role (i.e. Web Developers vs. IT administrators).

Web Developers Recommendations

• The Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool that identifies SQL Injection vulnerabilities in ASP code (ASP pages are the ones that have been under attack). In order to run MSCASI you will need source code access and MSCASI will output areas vulnerable to SQL injection (i.e. the root cause and vulnerable path is identified). In our view, fixing the root cause of the bug is the best way to eradicate vulnerabilities. MSCASI scans ASP source code and generates warnings for first order and second order SQL Injection vulnerabilities. Please refer to the SQL team’s blog and KB 954476 for more details.

IT/Database Administrators Recommendations (as well as Web developers)

We are recommending two of the new tools announced today. One can help identify SQL injection vulnerabilities by crawling the website.  The other one aims to block potential SQL injection attacks by filtering malicious requests.  The website crawler will be useful if you don't have access to the source code.  

• Microsoft worked with the HP Web Security Research group to release the Scrawlr tool. The tool will crawl a website, simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr uses some of the same technology found in HP WebInspect but has been built to focus only on SQL Injection vulnerabilities. This will allow an IT/DB admin to easily find vulnerabilities similar to the ones that have been used to compromise sites in recent attacks. No source code is required to run this tool. From a starting URL, the tool recursively crawls that URL in order to build up a site tree that will be then analyzed for SQL injection vulnerabilities. For more information check out the HP Web Security Research blog. 

• In order to block and mitigate SQL injection attacks (while the root cause is being fixed), you can also deploy SQL filters using a new release of URLScan 3.0. This tool restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from being executed on the server. It uses a set of keywords to block certain requests.  If a bad request is detected, the filter will drop the request and it will not be processed by SQL. That said, if a SQL injection flaw has been identified, we highly encourage you to fix the root cause of the problem instead of attempting to produce the perfect filter (since in our view this is error prone). Please refer to one of the two IIS blog posts (1, 2) and the technical documentation for more details.

The following table summarizes the pros and cons of these tools.