Google-Forscher knackt Samsungs Sicherheitsplattform Knox

Forscher von Googles Project Zero haben mehrere schwerwiegende Sicherheitslücken in Samsungs Knox-Plattform entdeckt. Die 2013 eingeführte Software dient als zusätzliche Sicherheitsschicht für Smartphones und wurde unter anderem vom US-Verteidigungsministerium und der National Security Agency für den Einsatz in Behörden zertifiziert. Laut Googles Gal Beniamini kann jedoch der Knox Hypersivor, der den Linux-Kernel während der Ausführung schützen soll, auf verschiedene Arten umgangen werden.

In einem Blogeintrag beschreibt Beniamini vier Fehler, die es ihm erlaubt haben, den Kernel-Schutz von Knox auf einem Galaxy S7 Edge mit Samsungs Exynos-Chipsatz auszuhebeln. Ein Angreifer wäre in der Lage, den Linux-Kernel des Android-Betriebssystems zu kompromittieren, um auf Systemdateien zuzugreifen, Malware einzuschleusen oder gar die vollständige Kontrolle über das System zu übernehmen.

Der Knox Hypervisor, der auch als Echtzeit-Kernel-Schutz (Real-time Kernel Protection, RKP) bezeichnet wird, nutzt die in ARM-Prozessoren enthaltene Sicherheitsfunktion TrustZone, um einen vertrauenswürdigen und sicheren Bereich zu schaffen, der strikt von der „normalen Welt“ des Betriebssystem getrennt ist. Zwar verfügt Android schon ab Werk mit Trusted Boot über einen Kernel-Schutz, der – wie der Name bereits suggeriert – aber nur während des Bootvorgangs greift.

Der Kernel-Schutz von Knox ist dem Forscher zufolge jedoch unter anderem durch die fehlerhafte Implementierung der Sicherheitsfunktion Kernel Adress Space Layout Randomization (KASLR) angreifbar. Samsung hatte sie mit der Knox-Version 2.6 eingeführt. KASLR soll verhindern, dass ein Angreifer die Speicheradresse des Kernels vorhersagt.

Die Sicherheitsfunktion generiere bei jedem Startvorgang einen zufälligen „Abstand“, um den die Basisadresse des Kernels im Speicher verschoben werde. Normalerweise werde der Kernel in eine feste Speicheradresse geladen, die einer festen virtuellen Adresse im virtuellen Adressraum des Speichers entspreche. KASLR verschiebe den Kernelspeicher und seinen Code jedoch um diesen zufälligen „Abstand“.

Da der Kernel um einen festen Wert verschoben werde, reiche jedoch ein einziger Pointer im Kernel, um den „Abstand“ zur Basisadresse zu berechnen. Um das zu verhindern gebe es die Android-Funktion „ktpr_restrict“, die den Wert eines Pointers durch einen Platzhalter im Format „%pK“ anonymisiere. Samsung nutze den Platzhalter jedoch mit einem „kleinen k“. „Das erlaubt es uns, den Inhalt von pm-qos zu lesen und den Wert des Pointers vom bekannten Abstand zur Basis-Adresse abzuziehen, was uns wiederum den Wert des KASLR-Abstands gibt“, ergänzte der Forscher.

Beniaminis Blogeintrag enthält Details zu drei weiteren Bugs, mit denen sich der Echtzeit-Kernel-Schutz ebenfalls aushebeln lässt. Darüber hinaus empfiehlt der Forscher Samsung verschiedene Maßnahmen, um die Sicherheitsfunktion vor künftigen Angriffen zu schützen. Alle Lücken seien Samsung bekannt und mit dem Januar-Update beseitigt worden.

Erst gestern veröffentlichte das Bundesamt für Sicherheit in der Informationstechnik einen Leitfaden mit Sicherheitsempfehlungen für die Konfiguration von Samsung Knox. Die Behörde weist ausdrücklich darauf hin, Android „mit Knox sei nicht gleich Android“ und die Knox-Plattform von Samsung biete eine robuste Sicherheitsarchitektur. Dieser Einschätzung dürften sich derzeit jedoch viele Besitzer der aktuellen Flaggschiffe Galaxy S7 und S7 Edge in Deutschland und anderen Länder nicht anschließen. Da Samsung den Januar-Patch mit dem Update auf Android 7.0 Nougat verbindet und sich die Auslieferung des Updates weltweit verzögert, befinden sich die meisten S7 und S7 Edge noch auf der Sicherheitspatch-Ebene 1. Dezember 2016. Sie sind also über die von Beniamini sehr gut dokumentierten Schwachstellen in Knox angreifbar. Das sollte auch zutreffend sein, wenn man die Empfehlungen des BSI zur Konfiguration von Knox befolgt hat.

[mit Material von Liam Tung, ZDNet.com]

Tipp: Sind Sie ein Android-Kenner? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de