Im neuesten Project Zero-Blogbeitrag hat das Team eine Möglichkeit entdeckt, Samsungs Echtzeit-Kernelschutz namens Knox Hypervisor zu umgehen.
Das Project Zero-Team von Google hat eine Reihe von Exploits überprüft, die es ermöglichen, Samsung-Telefone anzugreifen, auf denen die vermeintlich sichere Samsung Knox-Sicherheitssuite läuft. Der Blog stellt fest, dass alle Schwachstellen an Samsung weitergegeben wurden, das in einem Software-Update im Januar tatsächlich Korrekturen für sie veröffentlicht hat.
Hintergrund
Als Teil der von Samsung eingeführten Samsung Knox-Sicherheitssoftware-Suite gibt es eine Software namens a, die zwischen Android-Anwendungen und dem Kernel sitzt Hypervisor. Dies kann als zusätzliche Ebene zur weiteren Absicherung von Android-Geräten verwendet werden. Der Samsung Knox Hypervisor heißt „Echtzeit-Kernel-Schutz" oder kurz RKP, wie ich im Rest dieses Artikels darauf verweisen werde.
Der Kernel befindet sich unter RKP im Android-Software-Stack und die Anwendungen, die auf dem Gerät ausgeführt werden, befinden sich oben. Die Idee hinter RKP besteht darin, eine zusätzliche Sicherheitsebene für das Gerät bereitzustellen, da alle von ihm gestellten Anforderungen (Speicher und andere Ressourcen) berücksichtigt werden Anwendungen zum Kernel müssen zuerst Knox durchlaufen, das versucht zu erkennen, ob eine Anwendung etwas tut sollte nicht. RKP bietet außerdem Sicherheit durch Unklarheit mit einer zusätzlichen Ebene, um vertrauliche Informationen zu verbergen, die eine Anwendung zur Gefährdung des Geräts nutzen könnte.
Der Blog-Beitrag befasst sich ausführlich mit der Funktionsweise des Android-Speichers, des RKP und der Betriebssysteme im Allgemeinen. Deshalb habe ich ihn gekürzt und vereinfacht, um einen schnellen Überblick über die Entdeckungen zu geben. Ich empfehle Ihnen jedoch, den vollständigen Artikel zu lesen, wenn Sie Zeit haben, da er sehr aufschlussreich ist.
Exploit Nr. 1:
KASLR oder Kernel Address Space Layout Randomization ist der Prozess, bei dem die Position des Kernelcodes im Speicher beim Booten um einen zufälligen Betrag geändert wird. Bei jedem Booten des Geräts wird der Kernel in einen anderen Adressraum (Bereich im Speicher) geladen. Die Idee besteht darin, es schwieriger zu machen, herauszufinden, wo sich der Kernel-Code befindet, um ihn anzugreifen, da sich der Kernel-Code nach jedem Start um einen zufälligen Betrag im Speicher „verschiebt“. Das klingt nach einem großartigen Schritt, um potenzielle Angreifer abzuwehren, ist aber neu Forschung hat gezeigt, dass Sie dies tatsächlich verhindern können, ohne dass ein Softwarefehler oder eine Sicherheitslücke erforderlich ist, da KASLR tatsächlich sehr schwer auf robuste Weise gegen lokale Angreifer zu implementieren ist.
Im Fall der RKP-Software ist die Möglichkeit, KASLR zu umgehen, tatsächlich einfacher als die oben erwähnte Forschung. Der Speicher aller Android-Geräte wird durch Zeiger referenziert und um die Geräte vor Angriffen zu schützen, wann immer Android-Geräte drucken oder ausgeben (sei es auf dem Bildschirm oder zum Ablegen für Protokolle oder zum Debuggen) werden die Zeigerverweise anonymisiert, sodass es beim Lesen unmöglich ist, herauszufinden, wohin der Zeiger tatsächlich zeigt Ausgabe.
Stellen Sie sich Gedächtniszeiger wie ein Straßenschild vor, das auf einen Ort hinweist, und stellen Sie sich Anonymisierung als Verwischung vor. Ähnlich wie beim Fernsehen erfolgt die Anonymisierung nach den Dreharbeiten. Android wendet diese Anonymisierung auch zum Zeitpunkt der Ausgabe an und nur, wenn die Anonymisierung korrekt konfiguriert ist, wie der Autor angibt dass bei jedem Gerät, dem er begegnete, die Zeigeranonymisierung korrekt konfiguriert war. Das hört sich vielleicht so an, als wäre es sehr schwer zu knacken, aber Sie müssen nur einen einzelnen Hinweis finden (denken Sie an ein Straßenschild), der nicht anonymisiert (unscharf) ist. vom Kernel-Entwickler (Achtung, das ist kein durchschnittlicher Android-App-Entwickler), wenn der Zeiger in die Protokolle oder an einen anderen Ort geschrieben wird, z. B. Bildschirm oder ein Datei.
Wenn Sie also einen Zeiger finden, der nicht anonymisiert wurde, können Sie die zufällige Adressverschiebung des Kernels als Differenz zwischen den beiden berechnen. Interessanterweise konnte der Autor keinen ausnutzbaren Zeiger im Kernel finden, wohl aber im RPK wo Entwickler vergessen haben, einen Zeiger in der Debug-Ausgabe (Protokollierung) zu anonymisieren, was durch a zustande kam Tippfehler. Um die Zeiger in Android zu anonymisieren, muss man einen speziellen Code verwenden und es stellt sich heraus, dass die RPK-Entwickler fälschlicherweise einen verwendet haben Kleinbuchstabe „k“ statt eines Großbuchstabe „K“. Daher war es relativ einfach, den zufälligen Verschiebungsgrad des Kernelcodes herauszufinden und ihn anzugreifen.
Exploit Nr. 2:
Der nächste Exploit ist etwas komplexer: Samsung Knox schützt Ihr Gerät, indem es eine Reihe von Regeln auf den Gerätespeicher anwendet, um bösartigen Code zu stoppen. Die Regeln lauten wie folgt:
- Alle Seiten (Code im Speicher), mit Ausnahme des Kernel-Codes, sind als „Privileged Execute Never“ gekennzeichnet (was bedeutet, dass der Code hier niemals ausgeführt werden kann).
- Kernel-Datenseiten (vom Programm im Speicher verwendete Daten) werden niemals als ausführbar markiert (der Code kann hier also niemals ausgeführt werden).
- Kernel-Codepages (Code im Speicher) werden niemals als beschreibbar markiert (also kann kein bösartiger Code sie ändern)
- Alle Kernelseiten sind in der Übersetzungstabelle der Stufe 2 (der Tabelle, die sich zwischen der Anwendung und dem Kernel befindet, um zu verhindern, dass Anwendungen die tatsächlichen Speicherorte kennen) als schreibgeschützt markiert.
- Alle Speicherübersetzungseinträge sind für Anwendungen als schreibgeschützt markiert.
Wir konzentrieren uns auf Regel 3, da der Autor hier ein Problem bei der Umsetzung der oben genannten Regeln festgestellt hat. RPK markiert zwar den Speicher für den Kernel als schreibgeschützt, jedoch wurde durch ein Versehen der KASL eine Lücke entdeckt, die dazu führte Schreiben von Code in den angeblich „schreibgeschützten“ Abschnitt. Um den Speicherort des Kernels beim Booten zu verschleiern, wird dem Kernel Speicher zugewiesen, dieser ist jedoch viel größer als das Textsegment des Kernels. Durch die Zuweisung einer größeren Speichermenge wird es viel schwieriger, den tatsächlichen Kernel-Code zu finden, der irgendwo sein könnte, und wie wir oben gesehen haben, wird er bei jedem Start des Geräts zufällig verschoben.
Der Autor konnte bestätigen, dass der vom Kernel verwendete Speicher tatsächlich als „schreibgeschützt“ gekennzeichnet war, der Rest der großen Speichermenge, die zum Verbergen des Kernels verwendet wurde, jedoch schon nicht als „schreibgeschützt“ gekennzeichnet. Dies liegt daran, dass RKP nur den Bereich schützt, der den Text des Kernels enthält, nachdem die KASLR-Folie angewendet wurde.
Exploit Nr. 3
Im dritten Exploit konnte der Autor auf einen anderen Speicherbereich zugreifen, der ebenfalls schreibgeschützt sein sollte. Das RKP schützt den Speicher und verwendet a Hypervisor-Konfigurationsregister (HCR) zur Steuerung wichtiger Kernel-Operationen. Der Zweck des HCR besteht darin, gültigen und echten Kerneloperationen den Zugriff auf die Register zu ermöglichen und böswillige Angriffe zu blockieren. Dazu werden die Aufrufe an die Register überprüft, die die Virtualisierungsfunktionen steuern. Der HCR ist so konfiguriert, dass er bestimmte Vorgänge blockiert, die normalerweise verarbeitet würden, sodass RKP entscheiden kann, ob eine Anfrage zugelassen oder nicht zugelassen werden soll.
Bei diesem Exploit handelte es sich um die HCR-Steuerung deckt nicht zwei Register ab das erwies sich als sehr wichtig. Der Autor hat sich eingehend mit dem ARM-Referenzhandbuch befasst und herausgefunden, dass er mit dem ersten Register RKP für Anwendungen grundsätzlich deaktivieren konnte. Der "Das Systemsteuerungsregister für EL1 (SCTLR_EL1) ermöglicht die Steuerung des Systems auf höchster Ebene, einschließlich des Speichersystems.“ In einer perfekten Welt würde die Anwendung Speicher verwenden, der über das RKP zugeordnet wurde, sodass das RKP steuern könnte, worauf die Anwendung zugreifen könnte. Das Ausschalten dieses Registers ermöglichte jedoch die RKP soll deaktiviert werden indem das Gerät effektiv in den Zustand zurückversetzt wird, in dem es vor der Installation von RKP lief – was bedeutet, dass das Gerät ohne die zusätzliche Sicherheit, die RKP bietet, dem physischen Speicher zugeordnet wird. Das wiederum bedeutete, dass der Autor in den Speicher lesen und schreiben konnte, der ursprünglich und korrekt von der RKP-Software blockiert wurde.
Das zweite verpasste Register hatte einen subtileren Effekt, war aber letztendlich genauso verheerend für die Sicherheit. Der Übersetzungskontrollregister für EL1 Das Register (TCR_EL1) bezieht sich direkt auf die Speichermenge, mit der eine Anwendung arbeitet, die als Seite bezeichnet wird. RKP ist auf eine Seitengröße von 4 KB fest codiert, da AARCH64-Linux-Kernel (wie Android) eine Übersetzungsgröße von 4 KB verwenden. Das betreffende Register (TCR_EL1) stellt die ARM-Chipsätze auf die Größe des Speichers ein, der zurückgegeben werden soll. Es stellt sich heraus, dass Dieses Register ist nicht durch das HCR geschützt und daher kann ein Angreifer es ändern, da der Autor es auf eine Seitengröße von 64 KB geändert hat.
Dies bedeutet, dass bei Erfüllung der Anforderung durch RKP die tatsächliche Speichermenge, auf die zugegriffen werden kann, jetzt 64 KB statt 4 KB beträgt. Der Grund dafür ist, dass der ARM-Chipsatz immer noch die Seitengröße steuert und diese durch den Exploit auf 64 KB festgelegt wurde. Da das RKP im Rahmen der in Exploit Nr. 2 aufgeführten Regeln den Speicher vor dem Beschreiben schützt, ist der Speicher tatsächlich immer noch geschützt. Aber hier ist der Haken: Da RKP auf 4 KB fest codiert ist, ändert es sich nicht auf eine Seitengröße von 64 KB, wenn das Register aktualisiert wurde Nur die ersten 4 KB des Speichers sind geschützt dem Angreifer erlauben, dies zu tun was er will mit den restlichen 60kb.
Exploit Nr. 4
Der letzte Exploit, den der Autor zeigt, besteht darin, auf den Speicher zu verweisen, in dem sich die RKP-Software befindet, sodass der Angreifer die RKP-Software selbst angreifen könnte. Ein Trick, um diese Art von Angriff zu stoppen, den auch Linux-Kernel verwenden, besteht darin, die Zuordnung Ihres Programms zum Adressraum des virtuellen Speichers aufzuheben, sodass keine Anwendungen es angreifen können, weil sie nicht darauf verweisen können.
Denken Sie daran, dass es beim Speicher ausschließlich um Zeiger und Tabellen geht, die den physischen Speicher dem virtuellen Speicher zuordnen. Wie bei der normalen Verteidigung bei dieser Art von Angriff hebt RKP seine Karte auf, sodass es nicht angegriffen werden kann. Wenn der Kernel solche Fähigkeiten jedoch nicht bietet, ermöglicht RKP die Zuordnung und Markierung eines Speicherbereichs als Lese-/Schreibzugriff. Die einzige Prüfung besteht darin, dass es sich nicht um den zugrunde liegenden Kernel selbst handelt, da RKP keine Prüfungen durchführt, um festzustellen, ob es sich bei den Adressen, deren Zuordnung angefordert wird, um den Bereich handelt, in dem sich RKP selbst im Speicher befindet. Im Grunde RKP lässt sich neu kartieren zurück in den Adressraum, auf den Anwendungen zugreifen können und der sich nebenbei darauf auswirkt Der Speicher wird automatisch als Lese-/Schreibzugriff markiert Ein Angreifer kann den Speicher nun beliebig nutzen.
Abschluss
Eines der größten Probleme bei den vier oben aufgeführten Exploits besteht darin, dass der Autor erwähnt, wie schwierig sie aufgrund des Mangels an Funktionen im Basis-Android-Kernel durchzuführen wären. Ironischerweise stellte der sichere RKP-Hypervisor alle Werkzeuge bereit, die zur Durchführung der Angriffe erforderlich waren. Es zeigt, dass gut gemeinte Software manchmal mehr Probleme verursacht als sie löst, und wir haben Glück, dass wir Leute haben wie Gal Beniamini, die bereit sind, sich die Hände schmutzig zu machen und zu testen, ob die Dokumentation mit der tatsächlichen Software übereinstimmt tut.
Obwohl diese Exploits beängstigend wirken und Knox sehr verwundbar erscheinen lassen, möchte ich allen versichern, dass diese Probleme alle aufgetreten sind im Januar-Update behoben von Samsung. Darüber hinaus erfordern diese Exploits ein sehr tiefes Verständnis der ARM-Prozessoren und -Programmierung, sodass die Eintrittsbarriere für die Nutzung dieser Exploits astronomisch hoch ist.
Quelle: Projekt Null