Code-Manipulation

Ausprobiert: Chrome kann nach Zustimmung wohl mitlauschen

Der Browser Chrome könnte eine schwere Sicherheitslücke aufweisen: Webseiten können in einem Hintergrund-Fenster das Mikrofon aktivieren. Allerdings funktioniert der Angriff nicht so einfach, wie der Entdecker dies darstellt.
Von Hans-Georg Kluge

Zwei Chrome-Fenster - zweimal ist das Mikrofon aktiviert. Zwei Chrome-Fenster - zweimal ist das Mikrofon aktiviert. (Im Großbild zu sehen, wie Chrome die Fenster markiert).
Screenshot: teltarif.de
Ein Fehler im Google-Browser Chrome macht derzeit die Runde. Mit diesem sei es möglich, im Hintergrund ein Mikrofon zu aktivieren, so dass eine Webseite stets mithören kann, was im Raum gesprochen wird. Der Programmierer Tal Ater schreibt, aufgrund dieses Fehlers könne eine Webseite im Hintergrund ein Popup-Fenster öffnen. Auch dieses höre dann mit.

Die Kollegen von heise online schreiben dagegen, dieser Fehler sei so nicht reproduzierbar. heise führt an, in den eigenen Tests habe der von Ater bereitgestellte Beispielcode kein Fenster im Hintergrund öffnen können. Deswegen sei das Sicherheitsrisiko überschaubar, denn der Nutzer sehe ja das geöffnete Fenster einer böswilligen Webseite, welches mithören soll.

Ausprobiert: Beispielcode erzeugt ein Fenster im Hintergrund

Zwei Chrome-Fenster - zweimal ist das Mikrofon aktiviert. Zwei Chrome-Fenster - zweimal ist das Mikrofon aktiviert. (Im Großbild zu sehen, wie Chrome die Fenster markiert).
Screenshot: teltarif.de
In unseren Tests gelingt es dem Beispiel-Code dagegen auch in der aktuellen Chrome-Version, ein Fenster zu öffnen und dies sofort in den Hintergrund zu verschieben. Dabei spielte es keine Rolle, ob Chrome Popup-Fenster blockieren soll oder nicht. Das Argument der Kollegen gilt also offenkundig nicht für jedes System.

Wir sehen einen anderen Fehler: Offenbar funktionierte die Spracherkennung nicht richtig. Ein Blick in den Quellcode verrät, dass die Spracherkennungs-Routinen des Browsers dafür genutzt werden, die Eingabe in Text umzuwandeln. Dieser soll dann auf der Webseite, aber auch im Popup-Fenster, eingetragen werden. Im Tab der ursprünglichen Webseite zeigt der Browser an, dass das Mikrofon aktiv ist. Obwohl der Quellcode des Popup-Fensters ebenfalls die Spracherkennung aktivieren sollte, markiert der Browser das Fenster nicht entsprechend.

Wäre die Spracherkennung aktiv und würde sie funktionieren, könnte ein Javascript die gesprochenen und vor allem erkannten Inhalte an den Server der Webseite übertragen.

Chrome: Popup-Fenster zeigt keinen sofort sichtbaren Hinweis

Wir haben den Quelltext etwas modifiziert, so dass wir die Todolist-App in einem Popup starten konnten. Auch hier fragt uns der Browser, ob der Zugriff auf das Mikrofon erlaubt sei. In der URL-Zeile ist daraufhin nur eine Kamera zu sehen - diese weist auf den aktiven Zugriff hin. Wir öffnen mit einer erneut modifizierten, dem ursprünglichen Zustand wieder etwas näheren Version des Codes, ein weiteres Popup. In diesem Fenster sollte sofort die Spracherkennung starten. Wir sehen jedoch kein Anzeichen, dass der Browser diesen Befehl tatsächlich ausführt.

Zu erwarten wäre, dass der Code den gesprochenen Text in beide Browserfenster schreibt. Dies geschieht in unserem Fall jedoch nicht. Möglicherweise ist die Funktion in der deutschen Sprachversion des Browsers auch deaktiviert oder das Zusammenspiel aus Computer, Mikrofon, Browser und Webseite funktioniert nicht.

Google äußert sich gegenüber heise

Im vorderen Popupfenster ist das Mikrofon nicht aktiv. Im vorderen Popupfenster ist das Mikrofon nicht aktiv.
Screenshot: teltarif.de
Gegenüber heise habe sich Google dahingehend geäußert, der Fehler sei korrigiert. Tatsächlich gelingt es uns - wie beschrieben - nicht, im Hintergrund die Spracherkennung zu aktivieren. Wahrscheinlich hat Google tatsächlich dafür gesorgt, das jedes Fenster eine eigene Erlaubnis erhalten muss. Hier scheint Tal Ater in seinem ursprünglichen Blogpost zu irren - er hatte geschrieben, Google hätte zwar den Fehler behoben, aber nur intern, nicht aber in einer veröffentlichten Version.

Unsere Tests basieren auf dem Beispielcode von Tal Ater. Ob der Lauschangriff mit einem anderen Vorgehen erfolgreich auszuführen ist, können wir nicht probieren. Ater weist auf einen anderen Umstand hin, den wir - mangels HTTPS-Server - nicht testen konnten: Chrome merke sich die Entscheidung dann, wenn die Verbindung mit HTTPS verschlüsselt ist. In einem solchen Fall sind weitere Angriffs-Szenarien denkbar - sofern der Nutzer einmal zugestimmt hat. Allerdings muss der Angreifer dann wohl einen anderen Weg gehen als Ater ihn beschreitet.

Offline lässt sich der Fehler übrigens gar nicht reproduzieren: Lokalen HTML-Dateien verweigert Chrome vollständig, auf das Mikrofon zuzugreifen - die Dateien müssen auf einem Internet-Server liegen.

Fazit: Sicherheitslücke möglicherweise nicht vollständig geschlossen

In unseren Tests fragt der Browser stets nach, wenn wir in einem neuen Fenster die Spracherkennungsfunktion aktivieren wollen. Das ist zumindest ein ermutigendes Zeichen. Ob sich der Browser bei einer verschlüsselten Verbindung die Entscheidung des Nutzers merkt, können wir nicht überprüfen. Letztlich muss der Nutzer der Webseite vorher immer den Zugriff auf das Mikrofon gegeben haben. Es heißt also: Ob Flash oder Browser: Verlangt eine Webseite nach einem Mikrofon oder der Webcam, sollte die Entscheidung im Zweifel dagegen ausfallen.

Mehr zum Thema Browser