Studie beschreibt praktische Angriffe, die MTE-Schutzmaßnahmen in Chrome und Linux umgehen

Inhaltsverzeichnis der Links

Abstrakt

1. Einführung

2. Hintergrund

• Memory Tagging Extension
• Spekulativer Ausführungsangriff

3. Bedrohungsmodell

4. Finden von Tag-Leakage-Gadgets

• Tag-Leakage-Vorlage
• Tag-Leakage-Fuzzing

5. TIKTAG-Gadgets

• TIKTAG-v1: Ausnutzung der Spekulations-Schrumpfung
• TIKTAG-v2: Ausnutzung von Store-to-Load-Forwarding

6. Reale Angriffe

6.1. Angriff auf Chrome

7. Bewertung

8. Verwandte Arbeiten

9. Fazit und Referenzen

\

Reale Angriffe

Um die Ausnutzbarkeit von TIKTAG-Gadgets in MTE-basierter Schadensbegrenzung zu demonstrieren, entwickelt dieser Abschnitt zwei reale Angriffe gegen Chrome und den Linux-Kernel (Abbildung 9). Es gibt mehrere Herausforderungen beim Start realer Angriffe mit TIKTAG-Gadgets. Erstens müssen TIKTAG-Gadgets im Zieladressraum ausgeführt werden, was erfordert, dass der Angreifer Gadgets aus dem Zielsystem konstruiert oder findet. Zweitens muss der Angreifer den Cache-Zustand kontrollieren und beobachten, um die Tag-Prüfergebnisse zu leaken. Im Folgenden demonstrieren wir die realen Angriffe mit TIKTAG-Gadgets auf zwei reale Systeme: den Google Chrome Browser (§6.1) und den Linux-Kernel (§6.2), und diskutieren die Mitigationsstrategien.

\ 6.1. Angriff auf Chrome

Browser Ein Web-Browser ist eine primäre Angriffsfläche für webbasierte Angriffe, da er nicht vertrauenswürdige Webinhalte wie JavaScript und HTML verarbeitet. Wir geben zunächst einen Überblick über das Bedrohungsmodell (§6.1.1) und stellen ein TIKTAG-Gadget vor, das in der V8 JavaScript-Engine konstruiert wurde (§6.1.2). Dann demonstrieren wir die Wirksamkeit von TIKTAG-Gadgets bei der Ausnutzung des Browsers (§6.1.3) und diskutieren die Mitigationsstrategien (§6.1.4).

\ ==6.1.1. Bedrohungsmodell.== Wir folgen dem typischen Bedrohungsmodell von Chrome-Browser-Angriffen, bei dem der Angreifer darauf abzielt, Speicherfehler-Schwachstellen im Renderer-Prozess auszunutzen. Wir gehen davon aus, dass der Opfer-Benutzer die vom Angreifer kontrollierte Website besucht, die eine bösartige Webseite bereitstellt. Die Webseite enthält manipuliertes HTML und JavaScript, die Speicherfehler-Schwachstellen im Renderer-Prozess des Opfers ausnutzen. Wir gehen davon aus, dass alle modernsten Mitigation-Techniken von Chrome vorhanden sind, einschließlich ASLR [18], CFI [15], Site Isolation [53] und V8 Sandbox [56]. Zusätzlich nehmen wir als orthogonale Verteidigung an, dass der Renderer-Prozess zufälliges MTE-Tagging in PartitionAlloc [2] aktiviert.

\ ==6.1.2. Konstruktion von TIKTAG-Gadget.== In der V8 JavaScript-Umgebung wurde TIKTAG-v2 erfolgreich konstruiert und leckte die MTE-Tags jeder Speicheradresse. Wir haben jedoch kein konstruierbares TIKTAG-v1-Gadget gefunden, da die enge Zeitbeschränkung zwischen BR und CHECK in unserer spekulativen V8-Sandbox-Escape-Technik nicht realisierbar war (§A).

V8 TikTag-v2 Gadget. Abbildung 8 zeigt das TIKTAG-v2-Gadget, das in der V8 JavaScript-Engine konstruiert wurde, und seinen Pseudo-C-Code nach JIT-Kompilierung. Mit diesem Gadget kann der Angreifer erfahren, ob das geratene Tag Tg mit dem Tag Tm übereinstimmt, das target_addr zugewiesen ist. Der Angreifer bereitet drei Arrays vor: slow, victim, probe und einen idx-Wert. slow ist ein Unit8Array mit einer Länge von 64 und wird in BR aufgerufen, um die Zweigvorhersagefehler auszulösen. victim ist ein Float64Array mit Länge 64, das aufgerufen wird, um Store-to-Load-Forwarding auszulösen. probe ist ein Uint8Array mit Länge 512 und wird in

\ TEST aufgerufen, um das Tag-Prüfergebnis zu leaken. Ein idx-Wert vom Typ Number wird für den Out-of-Bounds-Zugriff auf victim verwendet. Der idx-Wert wird so gewählt, dass victim[idx] auf targetaddr mit einem geratenen Tag Tg zeigt (d.h. (Tg«56)|targetaddr). Um spekulativ auf target_addr außerhalb der V8-Sandbox zuzugreifen, nutzten wir die spekulative V8-Sandbox-Escape-Technik, die wir während unserer Forschung entdeckten und die wir in §A detailliert beschreiben. Zeile 8 von Abbildung 8a ist der BR-Block des TIKTAG-v2-Gadgets, der Zweigvorhersagefehler mit slow[0] auslöst.

\ Zeile 12-13 ist der CHECK-Block, der das Store-to-Load-Forwarding mit victim[idx] durchführt und auf target_addr mit einem geratenen Tag Tg zugreift. Wenn dieser Code JIT-kompiliert wird (Abbildung 8b), wird eine Grenzenprüfung durchgeführt, bei der idx gegen victim.length verglichen wird. Wenn idx ein Out-of-Bounds-Index ist, gibt der Code undefined zurück. Wenn das Laden des victim.length-Feldes jedoch lange dauert, führt die CPU die folgenden Store- und Load-Anweisungen spekulativ aus.

\ Danach implementiert Zeile 17 den TEST-Block, der mit dem weitergeleiteten Wert val als Index auf probe zugreift. Auch hier wird eine Grenzenprüfung von val gegen die Länge von probe vorangestellt, aber diese Prüfung ist erfolgreich, da PROBEOFFSET kleiner ist als die Länge des probe-Arrays. Folglich wird probe[PROBEOFFSET] nur dann zwischengespeichert, wenn das Store-to-Load-Forwarding erfolgreich ist, was der Fall ist, wenn Tg mit Tm übereinstimmt.

\ ==6.1.3. Chrome MTE-Bypass-Angriff.== Abbildung 9a veranschaulicht den gesamten MTE-Bypass-Angriff auf den Chrome-Browser mit willkürlicher Tag-Leakage-Primitive von TIKTAG-Gadgets. Wir gehen von einer Buffer-Overflow-Schwachstelle im Renderer-Prozess aus, wobei die Ausnutzung einer temporalen Schwachstelle (z.B. Use-after-Free) weitgehend gleich ist. Die Schwachstelle überfließt einen Zeiger (d.h. vuln_ptr) auf ein anfälliges Objekt (d.h. objvuln) und beschädigt das angrenzende Objekt (d.h. objtarget).

\ Mit der MTE-Durchsetzung von PartitionAlloc haben zwei Objekte mit einer Wahrscheinlichkeit von 14/15 unterschiedliche Tags. Um das Auslösen einer Ausnahme zu vermeiden, muss der Angreifer sicherstellen, dass die Tags von objvuln und objtarget gleich sind. TIKTAG-v2 kann verwendet werden, um das Tag von objvuln ( 1 ) und objtarget ( 2 ) zu leaken. Wenn beide geleakten Tags gleich sind, nutzt der Angreifer die Schwachstelle aus, was keinen Tag-Prüffehler auslösen würde ( 3 ). Andernfalls gibt der Angreifer objtarget frei und weist es neu zu und kehrt zum ersten Schritt zurück, bis die Tags übereinstimmen.

\ ==Auslösen des Cache-Seitenkanals.== Um ein TIKTAG-Gadget erfolgreich auszunutzen, muss der Angreifer die folgenden Anforderungen erfüllen:

i) Zweigtraining,

ii) Cache-Kontrolle und

iii) Cache-Messung. Alle drei Anforderungen können in JavaScript erfüllt werden.

Erstens kann der Angreifer den Zweigprädiktor trainieren, indem er das Gadget mit einem Wert ungleich Null slow[0] und In-Bounds-idx ausführt und den Zweigvorhersagefehler in BR mit einem Nullwert in slow[0] und Out-of-Bounds-idx auslöst.

Zweitens kann der Angreifer die Cache-Zeilen von slow[0], victim.length und probe[PROBE_OFFSET] mit JavaScript-Cache-Eviction-Techniken entfernen [8, 21, 70].

Drittens kann der Angreifer den Cache-Status von probe[PROBE_OFFSET] mit einem hochauflösenden Timer basierend auf SharedArrayBuffer messen [16, 58].

\ ==Ausnutzung von Speicherfehler-Schwachstellen.== Angesichts der geleakten MTE-Tags kann der Angreifer räumliche und zeitliche Speicherfehler-Schwachstellen im Renderer ausnutzen. Die Angriffsstrategie ist weitgehend dieselbe wie bei traditionellen Speicherfehler-Angriffen, sollte jedoch sicherstellen, dass die Schwachstelle unter Verwendung der geleakten Tags keinen Tag-Prüffehler auslöst. Wir detaillieren die Angriffsstrategie weiter in §C.

\ ==6.1.4. Mitigation.== Um die TIKTAG-Gadget-basierten MTE-Bypass-Angriffe im Browser-Renderer-Prozess zu mitigieren, können die folgenden Mitigationen eingesetzt werden:

i) Spekulative ausführungsbewusste Sandbox: Um Angreifer daran zu hindern, TIKTAG-basierte Angriffe aus einer Sandbox-Umgebung wie der V8-Sandbox zu starten, kann die Sandbox verstärkt werden, indem jeglicher spekulativer Speicherzugriff über die Speicherregion der Sandbox hinaus verhindert wird. Während moderne Web-Browser eine Sandbox verwenden, um nicht vertrauenswürdige Webinhalte vom Renderer zu isolieren, übersehen sie oft spekulative Pfade.

\ Zum Beispiel vermitteln die Chrome V8-Sandbox [56] und die Safari Webkit-Sandbox [1] die spekulativen Pfade nicht vollständig [27]. Basierend auf aktuellen Zeiger-Kompressionstechniken [64] können spekulative Pfade auf die Sandbox-Region beschränkt werden, indem die hohen Bits der Zeiger maskiert werden.

\ ii) Spekulationsbarriere: Wie in §5 vorgeschlagen, kann das Platzieren einer Spekulationsbarriere nach BR für potenzielle TIKTAG-Gadgets spekulative Tag-Leakage-Angriffe verhindern. Diese Mitigation ist jedoch möglicherweise nicht in der leistungskritischen Browser-Umgebung anwendbar, da sie einen erheblichen Leistungsoverhead einführen kann.

\ iii) Verhinderung der Gadget-Konstruktion: Wie in §5.2 vorgeschlagen, kann das TIKTAG-v2-Gadget durch Padding-Anweisungen zwischen Store- und Load-Anweisungen mitigiert werden. Ein TIKTAG-v1-Gadget, obwohl wir kein ausnutzbares gefunden haben, kann durch Padding-Anweisungen zwischen einem Zweig und Speicherzugriffen mitigiert werden, wie in §5.1 beschrieben.

\ 6.2. Angriff auf den Linux-Kernel

Der Linux-Kernel auf ARM wird häufig für mobile Geräte, Server und IoT-Geräte verwendet, was ihn zu einem attraktiven Angriffsziel macht. Die Ausnutzung einer Speicherfehler-Schwachstelle im Kernel kann die Privilegien des Benutzers eskalieren, und daher ist MTE ein vielversprechender Schutzmechanismus für den Linux-Kernel. TIKTAG-basierte Angriffe gegen den Linux-Kernel stellen einzigartige Herausforderungen dar, die sich vom Browser-Angriff unterscheiden (§6.1).

\ Dies liegt daran, dass der Adressraum des Angreifers vom Adressraum des Kernels isoliert ist, in dem das Gadget ausgeführt wird. Im Folgenden geben wir zunächst einen Überblick über das Bedrohungsmodell des Linux-Kernels (§6.2.1) und stellen ein Proof-of-Concept-TIKTAG-Gadget vor, das wir im Linux-Kernel entdeckt haben (§6.2.2). Schließlich demonstrieren wir die Wirksamkeit von TIKTAG-Gadgets bei der Ausnutzung von Linux-Kernel-Schwachstellen (§6.2.3).

\ ==6.2.1. Bedrohungsmodell.== Das Bedrohungsmodell hier ist weitgehend dasselbe wie das typischer Privilegien-Eskalationsangriffe gegen den Kernel. Insbesondere konzentrieren wir uns auf den ARM-basierten Android-Linux-Kernel, der mit Standard-Kernel-Schutzmaßnahmen gehärtet ist (z.B. KASLR, SMEP, SMAP und CFI). Wir nehmen weiter an, dass der Kernel mit einer MTE-Random-Tagging-Lösung gehärtet ist, ähnlich den produktionsreifen MTE-Lösungen wie Scudo [3].

\ Konkret wird jedem Speicherobjekt zufällig ein Tag zugewiesen, und ein zufälliges Tag wird zugewiesen, wenn ein Objekt freigegeben wird, wodurch sowohl räumliche als auch zeitliche Speicherfehler verhindert werden. Der Angreifer ist in der Lage, einen nicht privilegierten Prozess auszuführen und zielt darauf ab, seine Privilegien durch Ausnutzung von Speicherfehler-Schwachstellen im Kernel zu eskalieren. Es wird angenommen, dass der Angreifer Speicherfehler-Schwachstellen des Kernels kennt, aber kein MTE-Tag des Kernel-Speichers kennt. Das Auslösen von Speicherfehlern zwischen Kernel-Objekten mit

\ nicht übereinstimmenden Tags würde einen Tag-Prüffehler auslösen, was für reale Exploits unerwünscht ist. Eine kritische Herausforderung bei diesem Angriff besteht darin, dass das Gadget durch Wiederverwendung des vorhandenen Kernel-Codes konstruiert und durch die Systemaufrufe ausgeführt werden sollte, die der Angreifer aufrufen kann. Da die ARMv8-Architektur Benutzer- und Kernel-Seitentabellen trennt, können Benutzerraum-Gadgets nicht spekulativ auf den Kernel-Speicher zugreifen. Dieses Setup unterscheidet sich stark vom Bedrohungsmodell beim Angriff auf den Browser (§6.1), das den vom Angreifer bereitgestellten Code zur Konstruktion des Gadgets nutzte. Wir haben auch die eBPF-basierte Gadget-Konstruktion ausgeschlossen [17, 28], da eBPF für den nicht privilegierten Android-Prozess nicht verfügbar ist [33].

\ ==6.2.2. Kernel TikTag Gadget==. Wie in §4.1 beschrieben, müssen TIKTAG-Gadgets mehrere Anforderungen erfüllen, und jede Anforderung bringt Herausforderungen in der Kernel-Umgebung mit sich.

Erstens muss in BR ein Zweigvorhersagefehler mit cond_ptr ausgelöst werden, der aus dem Benutzerraum kontrollierbar sein sollte. Da neuere AArch64-Prozessoren das Zweigvorhersagetraining zwischen Benutzer und Kernel isolieren [33], muss das Zweigtraining aus dem Kernel-Raum durchgeführt werden.

Zweitens sollte in CHECK guessptr dereferenziert werden. guessptr sollte aus dem Benutzerraum erstellt werden, sodass es ein geratenes Tag (Tg) einbettet und auf die Kernel-Adresse (d.h. target_addr) zeigt, um das Tag (Tm) zu leaken. Im Gegensatz zur Browser-JavaScript-Umgebung (§6.1) werden vom Benutzer bereitgestellte Daten in Systemaufrufen stark bereinigt, sodass es schwierig ist, einen willkürlichen Kernel-Zeiger zu erstellen.

\ Zum Beispiel stellt accessok() sicher, dass der vom Benutzer bereitgestellte Zeiger auf den Benutzerraum zeigt, und das arrayindexnospec-Makro verhindert spekulativen Out-of-Bounds-Zugriff mit dem vom Benutzer bereitgestellten Index. Daher sollte guessptr ein vorhandener Kernel-Zeiger sein, insbesondere der anfällige Zeiger, der Speicherfehler verursacht. Zum Beispiel kann ein hängender Zeiger in Use-after-Free (UAF) oder ein Out-of-Bounds-Zeiger in Buffer Overflow verwendet werden. Schließlich sollte in TEST testptr dereferenziert werden, und testptr sollte aus dem Benutzerraum zugänglich sein. Um die Cache-Zustandsmessung zu erleichtern, sollte test_ptr ein Benutzerraum-Zeiger sein, der über ein Systemaufrufargument bereitgestellt wird.

\ ==Entdeckte Gadgets.== Wir haben den Quellcode des Linux-Kernels manuell analysiert, um das TIKTAG-Gadget zu finden, das die oben genannten Anforderungen erfüllt. Als Ergebnis fanden wir ein potenziell ausnutzbares TIKTAG-v1-Gadget in sndtimeruserread() (Abbildung 10). Dieses Gadget erfüllt die Anforderungen von TIKTAG-v1 (§5.1). In Zeile 10 (d.h. BR) löst die switch-Anweisung Zweigvorhersagefehler mit einem vom Benutzer kontrollierbaren Wert tu->tread (d.h. condptr) aus. In den Zeilen 14-17 (d.h. CHECK) wird tread (d.h. guessptr) durch vier Load-Anweisungen dereferenziert. tread zeigt auf ein struct sndtimer_tread64-Objekt, das der Angreifer willkürlich zuweisen und freigeben kann.

\ Wenn eine temporale Schwachstelle tread in einen hängenden Zeiger verwandelt, kann er als guessptr verwendet werden. In Zeile 20 (d.h. TEST) wird ein Benutzerraum-Zeiger buffer (d.h. testptr) in copytouser dereferenziert. Da dieses Gadget nicht direkt aus dem Benutzerraum erreichbar ist, haben wir eine geringfügige Änderung am Kernel-Code vorgenommen; wir haben die frühe Rückkehr für den Standardfall in Zeile 6 entfernt. Dies stellt sicher, dass auf den Puffer nur im spekulativen Pfad zugegriffen wird, um die Cache-Zustandsdifferenz aufgrund spekulativer Ausführung zu beobachten.

\ Obwohl diese Änderung in einem realen Szenario nicht realistisch ist, demonstriert sie die potenzielle Ausnutzbarkeit des Gadgets, wenn ähnliche Codeänderungen vorgenommen werden. Wir haben mehrere weitere potenziell ausnutzbare Gadgets entdeckt, konnten jedoch die Cache-Zustandsdifferenz zwischen Tag-Übereinstimmung und Nichtübereinstimmung nicht beobachten. Dennoch denken wir, dass es ein starkes Potenzial gibt, diese Gadgets auszunutzen. Das Starten TIKTAG-basierter Angriffe erfordert komplexes und sensibles Engineering, und daher konnten wir nicht mit allen möglichen Fällen experimentieren.

\ Insbesondere verlässt sich TIKTAG-v1 auf die Spekulations-Schrumpfung bei falschen Pfadereignissen, die auch Adressübersetzungsfehler oder andere Ausnahmen im Zweigvorhersagefehler-Pfad umfassen können. Da Systemaufrufe komplexe Kontrollflüsse beinhalten, wird die Spekulations-Schrumpfung möglicherweise nicht wie erwartet ausgelöst. Darüber hinaus können mehrere Gadgets ausnutzbar werden, wenn sich der Kernel-Code ändert. Zum Beispiel zeigte ein TIKTAG-v1-Gadget in ip6mr_ioctl() kein MTE-Tag-Leakage-Verhalten, als es aus seinem Systemaufrufpfad (d.h. ioctl) aufgerufen wurde. Das Gadget hatte jedoch Tag-Leakage, als es mit einem einfachen Kontrollfluss auf andere Syscalls (z.B. write) portiert wurde.

\ ==6.2.3. Kernel MTE-Bypass-Angriff.== Abbildung 9b veranschaulicht die MTE-Bypass-Angriffe auf den Linux-Kernel. Am Beispiel einer Use-after-Free-Schwachstelle nehmen wir an, dass der Angreifer ein entsprechendes TIKTAG-Gadget, SysTikTagUAF(), identifiziert hat, das in der Lage ist, das Tag-Prüfergebnis des durch die Schwachstelle erstellten hängenden Zeigers zu leaken. Zum Beispiel kann das TIKTAG-v1-Gadget in sndtimeruser_read() (Abbildung 10) das Tag-Prüfergebnis von tread leaken, das durch eine Use-after-Free- oder Double-Free-Schwachstelle zu einem hängenden Zeiger werden kann.

\ Der Angriff verläuft wie folgt: Erstens gibt der Angreifer ein Kernel-Objekt (d.h. objvuln) frei und hinterlässt seinen Zeiger (d.h. vuln_ptr) als hängenden Zeiger ( 1 ). Als Nächstes weist der Angreifer mit SysAllocTarget() ein weiteres Kernel-Objekt (d.h. objtarget) an der Adresse von objvuln zu ( 2 ). Dann ruft der Angreifer SysTikTag() mit einem Benutzerraum-Puffer (d.h. ubuf) auf ( 3 ) und leakt das Tag-Prüfergebnis (d.h. Tm == Tg), indem er die Zugriffslatenz von ubuf misst ( 4 ). Wenn die Tags übereinstimmen, löst der Angreifer SysExploitUAF() aus, einen Systemaufruf, der die Use-after-Free-Schwachstelle ausnutzt ( 5 ). Andernfalls weist der Angreifer objtarget neu zu, bis die Tags übereinstimmen.

\ ==Auslösen des Cache-Seitenkanals.== Wie in §6.1.3 erfordert eine erfolgreiche TIKTAG-Gadget-Ausbeutung i) Zweigtraining, ii) Cache-Kontrolle und iii) Cache-Messung. Für das Zweigtraining kann der Angreifer den Zweigprädiktor trainieren und Spekulation mit vom Benutzer kontrollierten Zweigbedingungen aus dem Benutzerraum auslösen. Für die Cache-Kontrolle kann der Angreifer den Benutzerraum-Puffer (d.h. ubuf) löschen, während die Kernel-Speicheradresse durch Cache-Line-Bouncing entfernt werden kann [25]. Für die Cache-Messung kann die Zugriffslatenz von ubuf mit dem virtuellen Zähler (d.h. CNTVCT_EL0) oder einem speicherzählerbasierten Timer (d.h. nahezu CPU-Zyklusauflösung) gemessen werden.

\ ==Ausnutzung von Speicherfehler-Schwachstellen.== TIKTAG-Gadgets ermöglichen das Umgehen von MTE und die Ausnutzung von Kernel-Speicherfehler-Schwachstellen. Der Angreifer kann das TIKTAG-Gadget im Kernel aufrufen, um spekulativ den Speicherfehler auszulösen und das Tag-Prüfergebnis zu erhalten. Dann kann der Angreifer das Tag-Prüfergebnis erhalten und den Speicherfehler nur dann auslösen, wenn die Tags übereinstimmen. Wir detaillieren den Linux-Kernel-MTE-Bypass-Angriffsprozess in §D.

\ ==6.2.4. Mitigation.== Um TIKTAG-Gadgets im Linux-Kernel zu mitigieren, sollten die Kernel-Entwickler die folgenden Mitigationen in Betracht ziehen:

i) Spekulationsbarriere: Spekulationsbarrieren können TIKTAG-v1-Gadgets im Linux-Kernel effektiv mitigieren. Um zu verhindern, dass Angreifer das Tag-Prüfergebnis über den Benutzerraum-Puffer leaken, können Kernel-Funktionen, die auf Benutzerraum-Adressen zugreifen, wie copytouser und copyfromuser, mit Spekulationsbarrieren gehärtet werden. Wie in §5.1 beschrieben, kann das Leaken von Tag-Prüfergebnissen mit Store-Zugriff mitigiert werden, indem eine Spekulationsbarriere vor dem Store-Zugriff (d.h. TEST) platziert wird.

\ Um beispielsweise die Gadgets zu mitigieren, die copytouser nutzen, kann eine Spekulationsbarriere vor dem Aufruf von copytouser eingefügt werden. Für Gadgets, die Load-Zugriff auf den Benutzerraum-Puffer verwenden, mitigieren die Barrieren die Gadgets, wenn sie zwischen dem Zweig und dem Kernel-Speicherzugriff (d.h. CHECK) eingefügt werden. Um beispielsweise die Gadgets zu mitigieren, die copyfromuser nutzen, sollten die Kernel-Entwickler die Kernel-Codebasis sorgfältig analysieren, um das Muster der bedingten Verzweigung, des Kernel-Speicherzugriffs und von copyfromuser() zu finden, und eine Spekulationsbarriere zwischen der Verzweigung und dem Kernel-Speicherzugriff einfügen.

\ ii) Verhinderung der Gadget-Konstruktion: Um potenzielle TIKTAG-Gadgets im Linux-Kernel zu eliminieren, kann der Kernel-Quellcode analysiert und gepatcht werden. Da TIKTAG-Gadgets auch durch Compiler-Optimierungen konstruiert werden können, kann eine Binäranalyse durchgeführt werden. Für jedes entdeckte Gadget können Anweisungen neu angeordnet oder zusätzliche Anweisungen eingefügt werden, um die Gadget-Konstruktion zu verhindern, gemäß den Mitigationsstrategien in §5.1 und §5.2.

:::info Autoren:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info Dieses Papier ist auf arxiv verfügbar unter CC 4.0 Lizenz.

:::

\