Die Forschungsgruppe von Google namens „Projekt-Zero“ hat eine kritische Zero-Day Sicherheitslücke im Microsoft Edge Browser entdeckt. Welche, auch nach einer 104-tägigen Karenzphase noch nicht mit einem Update versehen werden kann, da, so Microsoft (siehe den Kommentar 1), der Umfang der Lücke zu komplex sei, um diese in so kurzer Zeit zu beheben. Angesichts dieser Sicherheitslücke klingt die Werbung „The faster, safer way to get things done on the web“ zunächst nicht mehr ganz tauglich.

In diesem Artikel möchten wir kurz in die Sicherheitslücke einführen, anhand dieser Einführung eine Risikoeinstufung der Lücke vornehmen und Angriffsszenarien skizzieren.

Die Sicherheitslücke

Es handelt sich um eine „Bypass“-Sicherheitslücke, die eine weitere Schwachstelle im System benötigt, um beliebigen Code ausführen zu können. Insgesamt hat der Edge-Browser eine Sicherheitsarchitektur zu Grund liegen, die es Angreifern erschwert manipulierten Code mit (internen) Browserrechten auf dem Rechner auszuführen. Diese besteht zum einen aus dem „Code Integrity Guard“ (CIG) und dem „Arbitrary Code Guard“ (ACG). Die Aufgaben sind ebenfalls recht einfach beschrieben: CIG lädt ausführbaren Code und stuft diesen in „vertrauenswürdig“ (Trusted) oder „nicht vertrauenswürdig“ (Untrusted) ein. ACG hingegen verwendet einen Just-In-Time (JIT)-Compiler, zum Übersetzen des Codes, in einem eigenen Prozess und soll sicherstellen, dass der „Trusted-Code“ im Speicher nicht modifiziert wurde. Der ACG stellt so gesehen einen Integritätsschutz dar. Genau beschreibt Microsoft das Vorgehen hier.

Das Ziel eines Angreifers bei dieser „Bypass“-Sicherheitslücke ist, sich am ACG-Schutz vorbeizuschleusen, um seinen Untrusted-Code (Schadcode) auszuführen. Die Schwachstelle stellt also der JIT-Compiler dar. Ist ein Schadcode in der Lage vorherzusagen, an welcher Adresse im Speicher der JIT-Compiler den Befehl „VirtualAllocEx()“ ausführt, so kann dieser seinen sog. Payload (=Nutzdaten) entsprechend platzieren, d.h. um seinen Angriff entweder vorzubereiten oder direkt seinen Schadcode zu platzieren.

Zum Angriffsszenario

Zunächst ist es für einen Angreifer unmöglich (ohne weiteres) bereits geladenen Code im Speicher des „Opfers“ nachträglich zu manipulieren. Auch ist ein Angreifer nicht in der Lage neue Speicherblöcke zu reservieren, in denen der Code gespeichert werden soll. Nach dem Prinzip des JIT-Compilers, ist dieser jedoch in der Lage parallel zum Browsen neue Speicherblöcke für geladenen Code zu reservieren und zu modifizieren. Jedoch, und das ist wichtig hervorzuheben, kann dies nicht durch den Angreifer beeinflusst werden, dieser kann nur mit relativ hoher Sicherheit Vorhersagen treffen.

Diese Ausführungen zeigen, dass ein Angreifer nicht ohne weiteres in der Lage ist, durch das Ansteuern seiner manipulierten Seite die Kontrolle über den Browser zu übernehmen oder beliebigen Schadcode auf den Anwenderrechnern auszuführen.

Würde ein normaler Nutzer mit Edge eine manipulierte Webseite ansteuern, so müsste eine weitere Schwachstelle des Edge ausgenutzt werden, um diese „Zero-Day“ ausnutzen zu können. Ist der Angreifer jedoch dazu in der Lage, so ist die Bühne für, die seit Wochen in den Medien immer wieder erscheinende und sehr schwerwiegende Sicherheitslücke auf Prozessorebene, Spectre frei.

Risikoeinstufung

Angesichts der angeführten Beschreibung des Vorgehens, ist die Sicherheitslücke für sich allein als mittel bis schwer einzustufen, da die Folgen beliebig gravierend sein können und ähnliches Ausmaß annehmen können, wie bei FireFox. Diese gehen vom Datenklau bis hin zur Übernahme administrativer Rechte innerhalb der Nutzer-Hardware (Laptop, Handy, …) Angesichts des geringen Marktanteils von Edge, und dass es nur eine „Browser-Zero-Day“ Sicherheitslücke ist, lässt sich die Gewichtung auf ein „mittleres“ Sicherheitsrisiko festlegen.

| | | , ,