In association with heise online

31 July 2009, 12:55

More information about Microsoft's ATL problems

  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

Following the release of the emergency patches last Tuesday, more background information about the critical holes in the Active Template Library (ATL) has come to light. In his blog, Microsoft's SDL expert Michael Howard discusses the actual flaws in the ATL and explains why they were not intercepted by the Security Development Lifecycle.

The first flaw was one of those classical typos with far-reaching consequences that any C developer has probably made at some point. An unreleased version of the ATL contains the function call:

hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);

Due to the misplaced &, the call writes the address of the pointer into the pbArray field, not into the array itself. In this case, because of the explicit type cast to (void*), the compiler doesn't issue a warning.

However, Howard does not investigate why Microsoft's security experts rubber-stamped a flawed patch for the MSVidCtl ActiveX control in DirectShow whose ineffectiveness was almost immediately exposed by Halvar Flake and Dennis Elser in a very apt analysis and without their having any access to the source code.

The second bug seems to have allowed the kill bit mechanism to be bypassed. Howard does not discuss this issue any further, but it is likely that, due to insufficient type checking, an ActiveX control can be instantiated via CComVariant::ReadFromStream() without any prior security checks.

In another blog entry, David Ross of MSRC Engineering provides some information about the "defense-in-depth" measures of Internet Explorer. The patch in MS09-034 apparently causes the browser to block suspicious ATL calls by default. This reportedly also protects vulnerable ActiveX controls by third party vendors. In addition, the developers of ActiveX controls themselves can opt to prevent their controls from creating COM objects via IPersistStream* or IPersistStorage. Microsoft hasn't enabled this restriction for compatibility reasons; it has to be enabled for each individual control via a special registry key.

Finally, a background paper about the issues has been released by Dowd, Smith and Dewey, who triggered the whole spectacle. However, the 87 pages of Attacking InteroperabilityPDF, aren't an easy read.

See also:

(crve)

Print Version | Send by email | Permalink: http://h-online.com/-742749
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit