Broadcom-Sicherheitslücke: Vom WLAN-Chip das Smartphone übernehmen
Vor kurzem zeigten Google-Sicherheitsexperten, wie man die Firmware eines Broadcom-WLAN-Chips angreifen kann. Damit lässt sich auch das komplette Smartphone übernehmen - dank weiterer Bugs und weil die Hardware nicht hinreichend isoliert wurde.

Sicherheitslücken in der Firmware von Broadcom-WLAN-Chips haben es Gal Beniamini von Googles Project Zero erlaubt, die Kontrolle über den Chip zu erlangen. Doch offen blieb dabei die Frage, wie man von dort aus Kontrolle über das ganze Gerät erlangt. In einem zweiten Blogpost beschreibt Beniamini nun genau das. Dabei zeigt er zwei Wege auf - einen über Sicherheitslücken im Treiber und einen zweiten direkt über den PCI-Bus.
Zur Erinnerung: Mit Hilfe eines Buffer Overflow gelang es, die Firmware von Broadcom-WLAN-Chips zu exploiten, die in zahlreichen aktuellen Smartphones verbaut sind. Der WLAN-Chip ist dabei faktisch ein Mini-Computer mit eigenem Betriebssystem, unabhängig vom eigentlichen Smartphone-Betriebssystem. Damit ermöglichte der Exploit es zunächst "nur", Code auf dem WLAN-Chip selber auszuführen.
Kommunikation zwischen Firmware und Betriebssystem-Treiber
Die WLAN-Firmware nutzt dabei eine besondere Methode, um mit dem Treiber auf dem Betriebssystem zu kommunizieren: Sie codiert die Kommunikation über Ethernet-Frames mit einer bestimmten Id. Der Hintergrund: Die Chips werden in verschiedenen Bus-Systemen eingesetzt. Manche sind über PCI angebunden, andere über USB oder SDIO. In allen Fällen müssen jedoch Ethernet-Frames von der Firmware an den Treiber weitergegeben werden. Diese bieten somit eine generische Möglichkeit der Kommunikation.
In älteren Versionen der Broadcom-Firmware war es möglich, diese speziellen Kontroll-Ethernet-Frames auch direkt von außen via Netzwerk zu schicken. Doch in neueren Versionen führte Broadcom eine Filterfunktion in der Firmware ein. Aber, da der WLAN-Chip bereits exploitet war, stellte diese kein Hindernis dar. Der Exploit kann diesen Code einfach überschreiben und deaktivieren.
Beniamini fand im Android-Treiber des Broadcom-Chips gleich fünf verschiedene Memory-Corruption-Sicherheitslücken. Eine davon erwies sich als besonders gut geeignet für einen Exploit - ein typischer Heap Overflow.
Komplexer Exploit mittels Heap Spraying
Der gesamte Exploit ist extrem komplex. Da der Angreifer von außen kaum etwas über das aktuelle Speicherlayout des Systems weiß, muss er sich auf Heap Spraying verlassen. Letztendlich gelang es Beniamini, einen funktionierenden Exploit für ein Nexus 5 zu erstellen, der auch im Bugtracker von Project Zero heruntergeladen werden kann.
Doch auf manchen Geräten ist dieser Aufwand überhaupt nicht notwendig. Das hängt damit zusammen, wie der WLAN-Chip an das System angebunden ist. Auf älteren Systemen wurde hier häufig SDIO genutzt, doch laut Beniamini nutzen viele aktuelle Smartphones PCI-Express.
Eine bekannte Eigenschaft von PCI-Geräten ist es, dass diese direkten Zugriff auf den Arbeitsspeicher mittels DMA haben. Solche DMA-Angriffe können auch genutzt werden, um Laptops oder Desktop-Systeme mittels bestimmter Schnittstellen zu übernehmen, etwa Firewire oder Thunderboldt. Als Schutz vor DMA-Angriffen können modernere Systeme jedoch eine Technologie namens IOMMU nutzen. Damit lassen sich angeschlossene Geräte vom System isolieren und der Speicherzugriff unterbinden.
Isolationsmechanismus SMMU wird häufig nicht genutzt
ARM nutzt eine eigene Variante von IOMMU, eine sogenannte System Memory Mapping Unit (SMMU). Dass diese Technologie vorhanden ist, heißt aber nicht, dass sie auch genutzt wird. So fand Beniamini heraus, dass auf einem Nexus 6P, das Qualcoms Snapdragon 810 benutzt, SMMU für den WLAN-Chip nicht aktiv ist. Auch auf einem Galaxy S7 Edge, das mit Samsungs Exynos 8890 betrieben wird, war SMMU nicht aktiv.
Die Folge: Die Firmware des WLAN-Chips kann direkt auf den Arbeitsspeicher des Betriebssystems zugreifen und beispielsweise den Kernel-Code umschreiben. Auf solchen Systemen bedeutet ein Exploit der WLAN-Firmware also direkt auch eine Kompromittierung des gesamten Systems.
Fazit: bessere Isolierung und bessere Sicherheitsmechanismen für Firmwares
Bereits aus dem ersten Blogpost wurde klar, dass WLAN-Chips in Sachen Sicherheit aufrüsten sollten. Während auf Smartphone- und Desktop-Systemen Sicherheitsmechanismen wie ASLR, Stack Cookies und nicht ausführbare Speicherbereiche inzwischen sehr verbreitet sind, ist dies bei Firmwares meist nicht der Fall.
Doch auch an anderer Stelle sind Verbesserungen notwendig: Wenn Geräte über PCI oder andere Bussysteme angebunden sind, die auf den Speicher des Systems zugreifen können, sind Schutzmechanismen wie IOMMU dringend nötig. Und zu guter Letzt sollten Sicherheitsforscher wohl Treibern und Firmwares mehr Aufmerksamkeit widmen - und Hardwarehersteller sollten sich mehr um die Sicherheit ihres Codes kümmern.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Nein. Wieso?