Broadcom-Sicherheitslücken: Samsung schützt Nutzer nicht vor WLAN-Angriffen

Es ist wohl eines der beängstigendsten Angriffsszenarien, die man sich vorstellen kann: Googles Project Zero konnte kürzlich zeigen, dass sie mittels Bugs in der Firmware und im Treiber von Broadcom-WLAN-Chips ein Smartphone via Funksignale komplett übernehmen konnten.

Die betroffenen Broadcom-Chips werden in praktisch allen modernen Smartphones verwendet. Apple und Google selbst hatten Anfang April Sicherheitsupdates herausgegeben, in denen die Sicherheitslücken geschlossen wurden. Wir wollten wissen, ob Samsung ebenfalls Sicherheitsupdates bereitstellt - und haben bei der Pressestelle nachgefragt.

"Die Sicherheit und Privatsphäre unserer Kunden hat für Samsung oberste Priorität"

Das schreibt Samsung auf Anfrage von Golem.de. "Mit dem Android-7.0-Update, das seit Dezember 2016 sukzessive für alle Galaxy S7, Galaxy S7 edge und schnellstmöglich auch weitere Geräte bereitgestellt wird, steht bereits ein Patch zur Verfügung."

• 

Der Quellcode das S7 enthält einen Heap Buffer Overflow (Screenshot: Hanno Böck/Golem.de)

Das erscheint auf den ersten Blick nicht sehr glaubwürdig. Eine Sicherheitslücke, die Google im April veröffentlicht, ist von Samsung bereits im Dezember gefixt worden? Aus den zahlreichen Bugreports, die im Bugtracker von Project Zero zu finden sind, geht hervor, dass Gal Beniamini von Google viele der Sicherheitslücken erst Ende Dezember gefunden hatte.

Wir haben daher bei Samsung nochmals nachgefragt, ob diese Information korrekt ist. Telefonisch wurde uns das erneut bestätigt - die Aussage stimme, man habe bereits im Dezember einen Fix von Broadcom erhalten und mit dem Update für Android Nougat verteilt.

Hat Samsung die Unwahrheit gesagt?

Um das genauer nachvollziehen zu können, haben wir uns die Quellcodes des Linux-Kernels für das Galaxy S7, die Samsung aus Lizenzgründen bereitstellen muss, angesehen. Der Einfachheit halber haben wir uns auf einen einzigen Bug konzentriert - den Bug mit der Id CVE-2017-0569. Dieser Bug wurde im zweiten Teil von Googles Recherchen genutzt, um Code auf einem Smartphone auszuführen.

Es handelt sich dabei um einen relativ simplen Heap Buffer Overflow. Es wird ein Speicherbereich mit der Größe einer Variablen namens results->total_count erstellt. Anschließend werden Daten mit der Größe result->pkt_count in diesen Speicherbereich kopiert. Beide Werte kann der Angreifer kontrollieren. Bei korrekten Datenpaketen ist total_count immer größer als pkt_count, aber natürlich ist ein Angreifer nicht daran gebunden, korrekte Daten zu schicken.

Wir haben einen älteren Quellcode von Android Marshmallow vom April 2016 und den Android-Nougat-Quellcode vom Januar 2017 - den aktuellsten, der auf der Samsung-Webseite verfügbar ist - miteinander verglichen. Der Code für den Broadcom-Treiber unterschied sich nur minimal. Der Heap Overflow war noch in exakt derselben Form vorhanden. Weiterhin ging aus dem Datum im Header der Dateien hervor, dass die letzte Änderung dort offenbar im April 2016 vorgenommen wurde.

Damit ist klar: In Samsungs Kernel-Code für Android Nougat ist diese Sicherheitslücke weiterhin vorhanden - und die meisten anderen wohl auch. Wie es mit den Sicherheitslücken in der Firmware selbst aussieht, ist schwieriger nachzuvollziehen, da hierfür kein Quellcode bereitsteht.

Beunruhigend ist das allemal: Samsung scheint kein Interesse daran zu zeigen, bereits bekannte Sicherheitslücken auch zu beheben. Trotz mehrfacher Nachfrage erhalten wir falsche Auskünfte - wohl ein Zeichen dafür, dass man bei Samsung selbst nicht so genau Bescheid weiß.

Samsungs Exynos-SoC nutzt kein IOMMU

Wir hatten noch eine weitere Frage an Samsung: Neben den Lücken selbst zeigte Google ein gravierendes Designproblem: Die WLAN-Chips sind direkt über PCI angebunden. Um zu verhindern, dass in einem solchen Fall eine Sicherheitslücke in der Firmware gleich das Betriebssystem gefährdet, sollte eine Technik namens IOMMU genutzt werden, um die Hardware vom Restsystem abzuschotten. Andernfalls kann der WLAN-Chip direkt auf den Hauptspeicher zugreifen.

In Googles Nexus-Geräten wäre dafür ein SoC von Snapdragon verantwortlich, Samsung erstellt seine SoCs selbst. Sowohl der Snapdragon 810 von Qualcomm als auch der Exynos 8890 von Samsung nutzten kein IOMMU. Wir wollten von Samsung wissen, ob dieses Problem denn behoben wurde - darauf erhielten wir überhaupt keine Antwort.

Kritik an Samsungs Umgang mit Sicherheitslücken gab es schon öfter. Verbraucherschützer haben sogar schon versucht, Samsung wegen zögerlicher Sicherheitsupdates und mangelnder Transparenz zu verklagen. Im Kontext der Diskussion um die Stagefright-Lücken hatte Samsung angekündigt, sich zu bessern und künftig Sicherheitsupdates schneller bereitzustellen.