Mehr Infos zu Microsofts ATL-Problemen

Nach den beiden Eil-Patches vom Dienstag kommen mehr Informationen zu den Hintergründen der kritischen Fehler in der Active Template Library (ATL) ans Licht. Microsofts SDL-Experte Michael Howard konzentriert sich in seinem Blog auf die eigentlichen Fehler in der ATL und warum sie der Security Development Lifecycle nicht abfangen konnte.

Bei dem ersten Fehler handelte es sich um einen klassichen Typo mit weitreichenden Folgen, wie er wohl jedem C-Entwickler schon mal unterlaufen ist. In einer nicht veröffentlichten Version der ATL findet sich der Funktionsaufruf

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

der wegen des an dieser Stelle falschen & an die Adresse des Zeigers auf das Feld pbArray statt in das Array selbst schreibt. Wegen des expliziten Type Casts auf (void*) erzeugte der Compiler hier keine Warnung.

Einer Frage ging Howard in diesem Kontext jedoch nicht nach: Wieso winkten Microsofts Sicherheitsexperten einen nicht ausreichenden Patch des ActiveX-Controls MSVidCtl aus DirectShow durch, den Halvar Flake und Dennis Elser quasi sofort und ohne Zugang zum fraglichen Quellcode mit einer sehr treffenden Analyse als unwirksam entlarven konnten?

Der zweite Fehler ist anscheinend dafür verantwortlich, dass sich der Killbit-Mechanismus umgehen ließ. Howard lässt sich nicht weiter darüber aus, aber vermutlich ist es möglich, auf Grund nicht ausreichender Typprüfung über CComVariant::ReadFromStream() ein ActiveX-Control zu instantiieren, ohne dass vorher die Sicherheitsabfragen durchgeführt werden.

David Ross von MSRC Engineering gibt in einem anderen Blog-Eintrag ein paar Informationen zu den "in-Depth"-Schutzmechanismen des Internet Explorer. Offenbar blockiert der Browser durch den Patch in MS09-034 per Default verdächtige ATL-Aufrufe. Das soll auch die anfälligen ActiveX-Controls von Drittherstellern abschirmen.

Darüber hinaus können Entwickler von ActiveX-Controls selbst noch darauf verzichten, dass ihr Control COM-Objekte via IPersistStream* und IPersistStorage erstellen können. Diese Beschränkung hat Microsoft jedoch aus Kompatibilitätsgründen nicht aktiviert; sie muss durch einen speziellen Registry-Key für jedes Control einzeln scharf geschaltet werden.

Schließlich haben die Auslöser des Spektakels, Dowd, Smith und Dewey, ein Paper zu den Hintergründen veröffentlicht. Allerdings sind die 87 Seiten von Attacking Interoperability keine leichte Lektüre. (ju)