Google-Sicherheitsforscher: Android-Hersteller ermöglichen Sicherheitslücken

Der Google-Project-Zero-Mitarbeiter Jann Horn sieht Gefahren durch gerätespezifische Kernelanpassungen bei Android und fordert ein Umdenken bei den Herstellern.

In Pocket speichern vorlesen Druckansicht 32 Kommentare lesen
Google-Sicherheitsforscher: Android-Hersteller ermöglichen Sicherheitslücken

(Bild: Arthur_Shevtsov/Shutterstock.com)

Lesezeit: 2 Min.

Der deutsche Sicherheitsforscher Jann Horn, der derzeit für Googles Project Zero arbeitet und unter anderem an der Entdeckung der Prozessorlücken Spectre und Meltdown beteiligt war, kritisiert in einem Blogpost Android-Gerätehersteller. Deren gerätespezifische Änderungen am Kernel verursachen laut seiner Aussage Sicherheitslücken, die vermeidbar wären, wenn die Hersteller stattdessen diese Anpassungen entweder in Userspace-Treiber packen oder in den Upstream-Zweig einfließen lassen würden.

Nach derzeitigem Stand dürfen die Hersteller von Android-Smartphones und -Tablets für das jeweilige Gerät spezifische Anpassungen am Android-Kernel von Google vornehmen. Allerdings ist dieser Code oft auch eine Quelle von Sicherheitslücken und Angriffspunkten für Malware. Um diese Gefahr zu verringern, baut Google inzwischen zusätzliche Sicherheitsfunktionen ein. So beschränkt Android inzwischen den Zugriff auf diese herstellerspezifischen Gerätetreiber auf ausgewählte Softwareprozesse. Moderne Android-Smartphones greifen zudem durch extra dafür vorgesehene, so genannte Helper-Prozesse auf die Hardware zu, die zusammen das Hardware Abstraction Layer (HAL) bilden.

Um die Sicherheit weiter zu steigern, schlägt Jann Horn vor, dass die Hersteller solche Zugriffe zukünftig nicht mehr über eigene Treiber vornehmen, sondern dafür sicherere Schnittstellen verwenden. Das wären beispielsweise das Userspace-Treiber-Framework VFIO (Virtual Function I/O), das 2012 mit Linux 3.6 eingeführt wurde, und bei USB-Geräten der Zugriff über /dev/bus/usb/. Als Nebeneffekt würden sich dadurch auch leichter Kernel-Updates auf den Geräten einspielen lassen, weil langlebige Userspace-Schnittstellen zum Einsatz kommen und weniger Kernel-APIs, die sich ab und zu ändern. (chh)