In der heutigen Welt der Computertechnik sind Sicherheitsaspekte von zentraler Bedeutung, vor allem wenn es um den Schutz von Betriebssystemen und deren Benutzer geht. Ein wesentlicher Bestandteil der Sicherheitsarchitektur moderner Prozessoren ist die Kontrolle des Speicherzugriffs, insbesondere wenn es darum geht, den Zugriff privilegierter Betriebssystemkomponenten auf benutzerspezifische Speicherbereiche einzuschränken. ARM-Prozessoren verfügen in diesem Zusammenhang über eine spezielle Funktion namens PAN, was für „Privileged Access Never“ steht. Diese Technologie soll verhindern, dass der Kern des Betriebssystems (Kernel) unbeabsichtigt auf den Speicherbereich der Benutzeranwendungen zugreift und so potenzielle Angriffsmöglichkeiten minimieren. Doch wie sicher ist PAN wirklich, und welche Schwachstellen wurden bislang entdeckt? In diesem Artikel widmen wir uns diesen Fragen und beleuchten die Funktionsweise, die Herausforderungen und die Bedeutung dieses Features im Detail.
Das Konzept hinter PAN basiert auf der Idee, dass privilegierte Registerzugriffe, also jene des Kernels oder anderer geschützter Systemebenen, durch hardwareseitige Mechanismen kontrolliert und eingeschränkt werden. Konkret verhindert PAN Zugriffe vom Kernel auf Datenbereiche, die für Benutzerprozesse bestimmt sind, solange solche Zugriffe nicht ausdrücklich erlaubt sind. Das soll Angriffe erschweren, bei denen Hacker Sicherheitslücken im Kernel ausnutzen, um beispielsweise Schadcode im Benutzerspeicherplatz auszuführen oder sensible Daten auszulesen. Im ARM-Universum ist PAN daher eine Art Schutzschild zwischen den privilegierten und nicht privilegierten Speicherbereichen und dient als eine linie der Verteidigung gegen potentielle Exploits. Ein besonders interessanter Aspekt von PAN ist seine Implementierung auf der ARMv8-Architektur, die vor allem in vielen aktuellen Smartphones, Tablets und anderen eingebetteten Systemen Verwendung findet.
Hersteller wie Apple haben diese Technologie in ihren A10-Chips und neueren Versionen integriert. Dabei wird mithilfe spezieller Statusbits, beispielsweise PSTATE. PAN, geregelt, ob und wie privilegierte Zugriffe auf Speicherseiten mit Benutzerrechten erfolgen dürfen. Wenn dieser Zustand aktiviert ist, blockiert das System alle Datenzugriffe vom Kernel auf Speicher, der für Benutzeranwendungen reserviert ist. Dies macht das Leben von Angreifern schwieriger und erhöht die Sicherheit des gesamten Systems erheblich. Jedoch hat sich gezeigt, dass PAN nicht hundertprozentig wasserdicht ist. Sicherheitsforscher haben Sicherheitslücken entdeckt, die PAN umgehen können. Eine besonders auffällige Schwachstelle betrifft sogenannte „execute-only“-Speicherseiten, also Speicherbereiche, die nur ausführbar, aber nicht lesbar sind. Ursprünglich sollte PAN verhindern, dass privilegierte Systemteile solche Seiten als Daten lesen können.
Doch die ARM-Spezifikationen und deren Implementierungen zeigen, dass PAN hier versagt: Wenn der Kernel Speicherbereiche mit den Rechten „--x“, also nur ausführbar, aber weder lesbar noch schreibbar, adressiert, wird der PAN-Schutz nicht ausgelöst. Diese Eigenschaft ist umso bedeutender, da moderne Betriebssysteme wie iOS und frühere Versionen von Linux es erlaubten, solche execute-only Speicherseiten anzulegen. Das Problem beruht auf der Art und Weise, wie ARM den Speicherzugriff kontrolliert. Anders als bei einfachen Beispielen, in denen Speicherrechte sich auf Lese-, Schreib- und Ausführungsoperationen aufteilen lassen, ist die tatsächliche Hardwareimplementierung komplexer. Es existieren tatsächlich mehrere Bits im sogenannten Translation Table Entry, die bestimmen, welcher Kontext mit welchen Rechten zugreifen kann. Diese Rechte sind allerdings nicht vollständig unabhängig voneinander.
Während die Ausführungsrechte getrennt für den Benutzer- und Kernmodus gehandhabt werden, gibt es für Leseoperationen keine explizite Entziehungsmöglichkeit im Kernelmodus. Das bedeutet im Klartext, dass der Kernel Speicher prinzipiell immer lesen darf, selbst wenn für Benutzer nur das Ausführen erlaubt ist. Die Konsequenz daraus ist, dass PAN in der Praxis nicht korrekt erkennt, wenn der Kernel auf execute-only Benutzerspeicher zugreift, was eigentlich verhindert werden sollte. Dieses Verhalten führte dazu, dass Linux seine Unterstützung für execute-only User-Mappings wieder zurückzog, um dem Sicherheitsrisiko entgegenzuwirken. Apple-Geräte, die PAN verwenden, sind ebenfalls von dieser Problematik betroffen, wobei Apple auf alternative, proprietäre Schutzmechanismen wie APRR setzt, um die Fehlstelle zu kompensieren.
APRR ermöglicht Apple, feiner granulare Zugriffskontrollen hardwareseitig zu implementieren, sodass bestimmte Berechtigungen modifiziert oder entzogen werden können, was eine zusätzliche Schutzschicht gegenüber PAN bietet. Diese Entwicklungen verdeutlichen den Zwiespalt zwischen neuen, innovativen Sicherheitsansätzen und der Komplexität moderner Prozessorarchitekturen. Auf der einen Seite müssen Systeme geschützt bleiben, um das Risiko von Kernel-Exploits zu minimieren. Auf der anderen Seite ergeben sich bei der Vielfalt von Speicherzugriffsrechten und deren hardwareseitiger Umsetzung oft unerwartete Probleme und Lücken. Das PAN-Paradoxon zeigt, wie wichtig es ist, Sicherheitsfeatures nicht nur auf dem Papier, sondern auch im praktischen Betrieb kritisch zu hinterfragen und regelmäßig zu prüfen. Die Erforschung und Analyse solcher Schwachstellen ist essenziell, um zukünftige Design-Entscheidungen bei Hardwareherstellern und Betriebssystementwicklern zu beeinflussen.
So hatten Sicherheitsforscher bereits 2018 einen PAN-Bypass entdeckt und öffentlich gemacht, der zeigte, dass execute-only Mappings nicht den erwarteten Schutz herbeiführen. Trotz früher Warnungen kam es erst später zu offiziellen Maßnahmen, etwa bei Linux, die diese Sicherheitslücke adressierten. Dieser Fall unterstreicht, wie wichtig eine offene Kommunikation und schnelle Reaktion auf Sicherheitsvorfälle in der IT-Branche sind. Darüber hinaus verdeutlicht die Problematik von PAN auch die Herausforderungen bei der Kombination von verschiedenen Sicherheitsmechanismen. Betriebsysteme wie iOS setzen heute auf eine Vielzahl von Schutzmaßnahmen, darunter ASLR (Address Space Layout Randomization), Code-Signing, sandboxing und eben PAN. Doch je mehr Schutzschichten eingebaut werden, desto höher ist die Wahrscheinlichkeit, dass diese sich gegenseitig beeinflussen oder sogar inkompatibel werden.
Ein prominentes Beispiel ist die Kollision von PAN mit execute-only Speicherrechten – diese Interaktion führte zu der beschriebenen Schwachstelle. Es gilt deshalb, solche Wechselwirkungen bei der Entwicklung neuer Sicherheitsfeatures frühzeitig zu analysieren. Ein optimales Sicherheitsdesign muss daher nicht nur die einzelnen Features im Blick haben, sondern auch deren Zusammenspiel sowie deren Auswirkungen auf Systemperformance und Usability. Einige vorgeschlagene Workarounds für PAN-Schwachstellen, wie das Laden von Benutzerübersetzungsregistern (TTBR0_EL1) beim Kernel-Eintritt zu deaktivieren, werden wegen potenzieller Leistungseinbußen von Herstellern nicht umgesetzt. Stattdessen werden teilweise alternative Hardwarefeatures genutzt oder bestimmte Speichermappings ganz verboten.
Die Zukunft der Sicherheit bei ARM-basierten Systemen wird daher vermutlich eine Kombination aus verbesserten Hardwarefeatures, wie Apples APRR, und softwareseitigen Anpassungen auf Betriebssystemebene sein. Hersteller und Entwickler müssen eng zusammenarbeiten, um daraus robuste und performant arbeitende Sicherheitsarchitekturen zu schaffen. Regelmäßige Sicherheitsanalysen, öffentlich zugängliche Forschungsergebnisse und ein offenes Diskussionsklima sind hierfür Grundvoraussetzungen. Abschließend zeigt die Untersuchung von PAN und seiner Umgehung auf, dass selbst hoch entwickelte Sicherheitsmechanismen anfällig für Fehler sind, vor allem wenn komplexe Hardware-Spezifikationen und deren praktischen Implementierungen ineinandergreifen. Für Anwender ist es beruhigend zu wissen, dass Hersteller kontinuierlich an Verbesserungen arbeiten und Schwachstellen so schnell wie möglich adressieren.
Für Sicherheitsforscher bleibt das Thema jedoch ein spannendes Feld mit Herausforderungen und neuen Erkenntnissen, welche die Entwicklung zukünftiger Schutzmechanismen maßgeblich prägen werden. Die Sicherheit von Systemen ist letztlich ein dynamisches Gefüge, das ständiger Anpassung bedarf, gerade in Zeiten zunehmender Vernetzung und steigender Bedrohungslagen.
