Die Komplexität von Computerprogrammen nimmt seit Jahrzehnten zu. Infolgedessen haben auch die Anzahl und die Auswirkungen von Sicherheitslücken zugenommen. Memory-Corruption Angriffe sind seit Jahrzehnten eine der schwerwiegendsten Sicherheitsbedrohungen, trotz der enormen Anstrengungen der Security-Community: Nach 2019 veröffentlichten Statistiken von Microsoft sind 70% der in den letzten 10 Jahren behobenen Schwachstellen in Sicherheitsupdates Probleme mit der Speicherintegrität. Auch in den CWE Top 25 von 2021 stehen zwei der drei gefährlichsten Schwachstellenkategorien im Zusammenhang mit Speicherkorruption.

Es wurde eine Vielzahl von Ansätzen vorgeschlagen, die darauf abzielen, entweder Schwachstellen zu entdecken, bevor sie in einer Produktionsumgebung eingesetzt werden, oder Schwachstellen zu verhindern, indem man sie schwerer ausnutzbar macht. Zum ersten Fall gehören Strategien wie statische Analyse, Testsuiten und Fuzzing. Solche Methoden sind zwar wichtig und vorteilhaft, allerdings ist es nicht realistisch alle Softwarefehler zu finden: Die meisten Softwareprojekte leiden unter Memory-Corruption Schwachstellen, insbesondere wenn sie Legacy-Code enthalten.

Daher ist es entscheidend, Schutzmaßnahmen zu erforschen, zu entwickeln und einzusetzen, um das Ausnutzen solcher Schwachstellen erheblich zu erschweren oder sogar unmöglich zu machen. Drei prominente Ansätze dazu sind Software-Diversität (z.B. Randomisierung), Integritätsprüfungen (bspw. CFI) und Speicherisolierung (z.B. TEEs). Im Rahmen dieser kumulativen Dissertation werden Beiträge zu diesen drei Maßnahmen, aber auch Anwendungen für praktischere Probleme, präsentiert.

Die Idee von Software-Diversität besteht darin, das zu schützende Programm so zu verändern, dass eine oder mehrere seiner Eigenschaften, z.B. die Adresse von Code oder Daten, dem Angreifer nicht zugänglich sind. Da Speicherkorruptionen von der Adresse des Codes oder der Daten abhängen, muss der Angreifer alle Speicheradressen, welche für den Angriff erforderlich sind, entweder erraten oder auf andere Weise in Erfahrung bringen. Dies erhöht die Schwierigkeit des Angriffs erheblich. Mit Selfrando stellen wir einen Ansatz vor, welcher den ausführbaren Code eines Programms feingranular randomisiert. Im Gegensatz zu früheren Veröffentlichungen, führt unser Ansatz die Randomisierung jedes Mal durch, wenn die Software gestartet wird. Auf diese Weise kann das gleiche Programmpaket über herkömmliche Kanäle an alle Benutzer verteilt werden, aber jede Ausführung bekommt ein anderes Speicherlayout. Selfrando wurde erfolgreich in den privaten Tor-Browser integriert und mit der gehärteten Version des Tor-Browsers für Linux ausgerollt.

Das Prinzip von Control-Flow Integrity (CFI) besteht darin, indirekte Kontrollflusstransfers zu instrumentieren, um das berechnete Ziel zu prüfen bevor der Kontrollflusstransfer durchgeführt wird. Als Beispiel für einen groben CFI-Ansatz können indirekte Call-Instruktionen instrumentiert werden, um nur Aufrufe an die Startadressen bekannter Funktionen zu erlauben. Es wurde eine Vielzahl von CFI-Ansätzen mit unterschiedlicher Granularität vorgeschlagen. Angesichts dieser Vielfalt ist es wichtig, die Sicherheitsgarantien der einzelnen Verfahren quantifizieren zu können. Dazu stellen wir CFInsight vor, ein Benchmark für CFI-Sicherheit. Im Gegensatz zu vorherigen Ansätzen basiert unsere Analyse auf den Eigenschaften der Pfade zwischen indirekten Call-Instruktionen und System-Calls, die Angreifer erreichen müssen, um mit dem Betriebssystem oder dem Dateisystem zu interagieren. Unsere Metrik basiert auf quantitativen Messungen dieser Pfade und gibt an, wie schwer es ist, einen Angriff zu konstruieren.

Bei der Speicherisolierung werden Barrieren zwischen verschiedenen Softwarekomponenten eingesetzt, so dass eine Schwachstelle in einer dieser Komponenten nicht zur Ausnutzung einer anderen genutzt werden kann. Die Speicherisolierung kann ausschließlich in Software, oder mit Hilfe von Hardware-Erweiterungen, z.B. Trusted Execution Environments (TEEs), realisiert werden. Speicherisolierung ist besonders vorteilhaft für Software, die aus einer beträchtlichen Anzahl verschiedener Komponenten besteht, insbesondere wenn einige dieser Komponenten ungeprüfte Daten verarbeiten. Dies ist bei Webbrowsern der Fall, bei denen ein Angreifer den Just-In-Time-Compiler (JIT) angreift und ihn zwingen kann, bösartigen Code zu erzeugen. Daher stellen wir JITGuard vor, welches Speicherisolierung und ein TEE nutzt, um die internen Daten des JIT-Compilers eines Browsers vor Angreifern zu schützen. Im Gegensatz zu alternativen Ansätzen behält unsere Konstruktion die bestehende synchrone Aufrufsemantik bei und erfordert keine komplexen Abänderungen im ursprünglichen Code.

Speicherisolierung und insbesondere TEEs können für eine Reihe von weiteren Zwecken eingesetzt werden, unter anderem um die Vertraulichkeit einer Komponente zu gewährleisten. Es gibt jedoch eine Kategorie von Angriffen, mit denen die Vertraulichkeit der Speicherisolierung besonders effektiv gebrochen werden kann. Diese Angriffe nutzen Seitenkanäle aus, um Informationen aus einer Komponente zu extrahieren, ohne direkt mit dieser zu interagieren. Im Folgenden stellen wir unsere Vorschläge für rein software- und hardwarebasierte Gegenmaßnahmen gegen diese Angriffe vor.

Ein traditioneller Ansatz zur Einschränkung von Seitenkanal-Lecks besteht in der manuellen Entwicklung alternativer Algorithmen, was erhebliche Fachkenntnisse erfordert und höchst fehleranfällig ist. Stattdessen stellen wir DR.SGX vor, eine reine Softwarelösung, die automatisch alle in einem TEE verwendeten Daten durch eine feingranulare Randomisierung des Speicherlayouts schützt. Das Speicherlayout der Daten wird in regelmäßigen Abständen neu randomisiert, um das Datenleck während längerer Laufzeiten weiter zu begrenzen.

Ein anderer gängiger Ansatz zur Begrenzung von Cache-basierten Seitenkanal-Lecks ist die Partitionierung der Caches, was zu einer reduzierten Leistung führt. Bei unserem Projekt HybCache handelt es sich um eine neue Cache-Architektur, welche gezielt Seitenkanal-Lecks begrenzt. Dabei greift der sicherheitskritische Code auf eine Teilmenge des Cache vollständig assoziativ zu, wobei eine zufällige Replacement-Policy verwendet wird, die ein adressenspezifisches Informationsleck verhindert. Gleichzeitig greift unkritischer Code auf traditionelle Weise auf den Cache zu, was im Gegensatz zur Cache-Partitionierung keine Leistungseinbußen zur Folge hat.

Abschließend beschreiben wir zwei praktische Anwendungsfälle, die zeigen, wie TEEs zur Verbesserung von Protokollen eingesetzt werden können. Zunächst präsentieren wir VoiceGuard, ein TEE-basiertes Design für ein Spracherkennungssystem, das sowohl die Sprachdaten des Benutzers als auch das maschinelle Lernmodell des Anbieters vor der Offenlegung schützt. Zweitens stellen wir FastKitten vor, ein TEE-basiertes Protokoll, das eine schnelle und effiziente Ausführung von Smart Contracts in Kryptowährungen ermöglicht, welche keine Smart Contracts unterstützen.