Print

Welcome to Smokey's Security Forums.

Guests have only limited access to the board and it's features, please consider registering to gain full access!

Registration is free and it only takes a few moments to complete.

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MaB69]

ATL vulnerability developer deep dive
28 July 2009, 6:53 pm

This morning we released MS09-035 to address ATL vulnerabilities in Visual Studio. This blog post will help you answer the following questions:

What are the ATL vulnerabilities? Which versions of ATL are vulnerable?

How can I tell if my ActiveX control is affected?

How can I fix a vulnerable control?

What are the ATL vulnerabilities? Which versions of ATL are vulnerable?

There are three ATL vulnerabilities discussed in the bulletin:

CVE-2009-2493: Remote code execution which is caused due to instantiation of arbitrary objects which can bypass related security policies such as the killbit.

CVE-2009-2495: Information disclosure.

CVE-2009-0901: Remote code execution which is caused due to VariantClear() call on a variant that was not correctly initialized.

The following table tells which versions of ATL are affected by each bulletin.

 

CVE-2009-2493

CVE-2009-2495

CVE-2009-0901

Visual Studio 2002 SP1 (out of support)

Yes

Yes

Yes

Visual Studio 2003 SP1

Yes

Yes

Yes

Visual Studio 2005 SP1

**

Yes

**

Visual Studio 2008 RTM

**

Yes

**

Visual Studio 2008 SP1

**

Yes

No

Visual Studio 2010 Beta

No

No

No

** Controls and components built with Visual Studio 2005 SP1 and Visual Studio 2008/SP1 may be less affected because a new safe macro PROP_ENTRY_TYPE[_EX] was introduced in Visual Studio 2005 SP1. This new macro solves the problem almost entirely. Furthermore, starting with Visual Studio 2008, the PROP_ENTRY unsafe macro was deprecated. Thus, controls and components built using Visual Studio 2008/SP1 are less likely to be vulnerable. For further information review this resource article.

Several things we would like to clarify here:

Visual Studio itself is not vulnerable. Instead, controls and components built with the vulnerable ATL headers may be impacted and similarly, users with such controls and components installed may be subject to attack.

If you have built a control or component based on an affected ATL version, your control or component may be vulnerable. There are several conditions that are needed to reach the vulnerable ATL code which are discussed later on in this blog post.

These vulnerabilities apply to any control or component built with ATL if the necessary conditions are present.

How can I tell if my control is affected? How can I fix it?

You need to review the source code of your control or component. Please refer to the detail guidance in the following resource article.

Do I need to issue a killbit/phoenix bit for older controls?

If you decide there is no reason for your control to be ever hosted in IE, please consider issuing a killbit for it. For more information about the killbit, please refer to SRD “killbit” blog series. Microsoft, for example, issued the killbit as the final fix for the msvidctl.dll issue (MS09-032).

If you decide to fix the vulnerable control, we highly encourage you to issue a killbit for the old control and a phoenix bit for the updated control. The Kill-bit FAQ three part series explains this in detail.

The Kill-Bit FAQ: Part 1 of 3

The Kill-Bit FAQ: Part 2 of 3

The Kill-Bit FAQ: Part 3 of 3

- Arthur Wongtschowski, Windows Sustained Engineering- Chengyun Chu, MSRC Engineering

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

Source: Security Research & Defense