Seiten umblättern: eine neue Linux-Schwachstelle in nf_tables und verbesserte Exploit-Techniken

 (pwning.tech)
1 Punkte von GN⁺ 2024-03-27 | 1 Kommentare | Auf WhatsApp teilen
  • CVE-2024-1086 im Linux-Kernel-nf_tables erzeugt durch fehlgeschlagene Eingabevalidierung von Netfilter-Verdicts ein Double-Free von sk_buff und kann unter passenden Bedingungen zu lokaler Rechteausweitung führen
  • Der Angriffspfad sorgt dafür, dass ein während NF_DROP freigegebenes skb wie NF_ACCEPT weiterverarbeitet wird, sodass dasselbe Objekt später im Pfad erneut freigegeben wird
  • Das PoC wurde gegen KernelCTF-Mitigation, Debian, Ubuntu und Vanilla-Kernel verifiziert; mindestens der Bereich v5.14.21~v6.6.14 ist je nach kconfig betroffen, und im Februar 2024 wurde ein Fix in den Stable-Branches verteilt
  • Der Kern ist Dirty Pagedirectory: PTE- und PMD-Seiten werden doppelt auf dieselbe physische Seite allokiert, sodass sich mit reinen User-Space-Lese-/Schreibzugriffen beliebige physische Adressen über einen datenorientierten KSMA-Ansatz ansprechen lassen
  • In Kombination mit physischer KASLR-Erkundung, modprobe_path-Umgehung, dateiloser Ausführung und File-Descriptor-Verknüpfung für Namespace-Escapes ergibt sich ein praxisnahes LPE-Beispiel, das zugleich Kernel-Speicherverwaltung und Netzwerk-Subsystem angreift

Bedingungen der Schwachstelle und betroffener Bereich

  • Der nf_tables-Bug ist als CVE-2024-1086 registriert; der Kern des Problems ist eine fehlgeschlagene Eingabevalidierung, die bei der Verdict-Verarbeitung in Linux Netfilter positive Drop-Errors zulässt
  • Für den Exploit sind folgende Bedingungen nötig
    • nf_tables muss aktiviert sein
    • Unprivilegierte User-Namespaces müssen aktiviert sein
    • Bei großen Distributionen wie Debian und Ubuntu ist genau diese Standardkonfiguration die Angriffsgrundlage
  • Nach den Tests gehören die Stable-Branches linux-5.15.y, linux-6.1.y, linux-6.6.y zum betroffenen Bereich; linux-6.7.1 ist ebenfalls möglich
  • Im Februar 2024 wurde ein Bugfix in den Stable-Branches ausgeliefert
  • Der PoC-Quellcode ist im CVE-2024-1086 PoC repository veröffentlicht

Codepfad, der das Double-Free erzeugt

  • Ein Netfilter-Verdict ist ein Wert, der entscheidet, ob ein Paket verworfen, akzeptiert, in eine Queue gestellt usw. wird
  • Der verwundbare Ablauf beginnt damit, dass nft_verdict_init() den vom Nutzer gelieferten Verdict-Wert nicht streng genug einschränkt, sodass sich ein Wert setzen lässt, der wie NF_DROP aussieht, dessen Drop-Error aber positiv ist
  • nf_hook_slow() betrachtet die unteren Bits des Verdicts; wenn es als NF_DROP erkannt wird, wird das skb zuerst mit kfree_skb_reason() freigegeben
  • Wenn danach das Ergebnis von NF_DROP_GETERR() als ein Wert zurückkommt, der NF_ACCEPT entspricht, behandelt der aufrufende Code das Paket als akzeptiert und setzt die Verarbeitung fort
  • Dadurch wird ein bereits freigegebenes skb auf einem späteren Pfad erneut freigegeben, womit ein Double-Free-Primitive entsteht

Betroffene Objekte und Paketverarbeitung

  • Das Double-Free betrifft struct sk_buff aus skbuff_head_cache sowie das Objekt sk_buff->head
  • sk_buff->head enthält den eigentlichen Paketinhalt und kann je nach Größe des IPv4-Pakets von kmalloc-256 bis zu order-4-Seiten des Buddy-Allocators allokiert werden
  • Das PoC ist so ausgelegt, große IP-Pakete zu verwenden, damit der Pfad über den Buddy-Allocator statt über den Slab-Allocator läuft
  • Die IPv4-Fragmentation Queue wird genutzt, um das zweite Freigeben des skb zu verzögern oder gezielt zu einem gewünschten Zeitpunkt auszulösen
  • Wenn beschädigte skb-Felder im Paketpfad verwendet werden, kann das zu einem Kernel-Panic führen; deshalb werden TCP-/UDP-Stacks vermieden und stattdessen bestimmte IPv4-Fragment-Fehlerpfade genutzt

Testumfang und Erfolgsquote

  • In Umgebungen mit Vanilla-Kernel, KernelCTF, Debian und Ubuntu wurden mehrere Kernel-Versionen und Konfigurationen getestet
  • Zu den erfolgreichen Fällen gehören folgende Umgebungen
    • Linux v5.14.21, v5.15.148, v5.16.20, v5.17.15, v5.18.19, v5.19.17, v6.0.19
    • Linux v6.1.55 mit KernelCTF Mitigation v3
    • Linux v6.1.69 auf Debian Bookworm 6.1.0-17
    • Linux v6.1.72 auf KernelCTF LTS
    • Ubuntu Jammy v6.2.0-37
    • Linux v6.2.16, v6.3.13
  • Zu den fehlgeschlagenen Fällen zählen v5.4.270, v5.10.209, v6.4.16, Ubuntu Jammy v6.5.0-15, v6.5.13, v6.6.14, v6.7.1 und weitere
  • Einige Fehlschläge ab v6.4.0 stehen mit der bad_page()-Erkennung durch CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y in Verbindung
  • In der Umgebung v6.4.16 lag die Erfolgsquote bei 99,4 %, in manchen Fällen sank sie auf 93,0 %; die Stichprobengröße betrug jeweils n=1000

Art des Fixes

  • Der zunächst vorgeschlagene Fix hätte in der Mitte des Netfilter-Stacks eine Breaking Change verursachen können
  • Der Fix des Netfilter-Maintainers schränkt Verdicts aus Nutzereingaben bereits auf API-Ebene strenger ein
  • Der Patch verwirft DROP-/QUEUE-Verdict-Parameter aus Userland-Eingaben
  • Laut CVE-Beschreibung ließ nft_verdict_init() positive Werte als Drop-Error im Hook-Verdict zu, und nf_hook_slow() konnte in einer Überlappung von NF_DROP und NF_ACCEPT ein Double-Free erzeugen
  • Der Fix ist unter [PATCH nf] netfilter: nf_tables: reject QUEUE/DROP verdict parameters. zu sehen

Dirty Pagedirectory und Zugriff auf beliebigen physischen Speicher

  • Die zentrale Technik des PoC ist Dirty Pagedirectory, eine Abwandlung der bestehenden Technik Dirty Pagetable
  • Die Kernidee ist, PTE-Seiten und PMD-Seiten doppelt auf dieselbe physische Seite zu allokieren
  • Schreibt man in einem virtuellen Adressbereich Werte, die wie PTE-Einträge aussehen, interpretiert ein anderer virtueller Bereich diese als Seitentabelleneinträge und mappt damit die angegebene physische Seite
  • So funktioniert der Ansatz als Kernel-Space-Mirroring-Angriff, der allein mit User-Space-Adress-Lese-/Schreibzugriffen beliebige physische Adressen mitsamt Berechtigungs-Flags setzt und anspricht
  • Er wird eingesetzt, um Schutzmechanismen wie virtuelles KASLR, KPTI, SMAP, SMEP und CONFIG_STATIC_USERMODEHELPER zu umgehen

Manipulation des Seiten-Allocators

  • An der Seitenallokation im Kernel sind Slab-Allocator, Buddy-Allocator und PCP-Allocator beteiligt
  • skb heads verwenden bei großen Größen order-4-Seiten des Buddy-Allocators, PTE-/PMD-Seiten dagegen order-0-Seiten, daher greifen sie nicht direkt ineinander
  • Um das zu lösen, werden zwei Methoden der Page Conversion verwendet
    • PCP list draining: Eine order-4-Seite wird in die Buddy-Freiliste gelegt, dann wird die PCP-order-0-Freiliste geleert, damit sie vom Buddy-Allocator erneut mit order-0-Seiten befüllt wird
    • Race Condition: Während des zweiten Free wird ein Wettlauf ausgenutzt, um eine order-4-Seite in die order-0-Freiliste zu bringen
  • PCP list draining ist die einfachere, stabilere und schnellere Methode
  • Die Race-Condition-Methode wurde in einem frühen KernelCTF-Exploit verwendet, gilt aber als obsolet, weil sie von Umgebungen mit hoher Serial-TTY-Latenz wie QEMU-VMs abhängt

Umgehung der KernelCTF-Mitigation

  • In der KernelCTF-Mitigation-Umgebung war die aktiv zu umgehende Schutzmaßnahme die Freilist-Corruption-Prüfung für sk_buff
  • skbuff_head_cache->offset == 0x70, daher überlappt der Freilist-Next-Pointer mit skb->len
  • Nach dem ersten Free des skb wird skb->len teilweise durch den Freilist-Pointer überschrieben; wenn sich dieser Wert später beim Paket-Parsing ändert, kann die Corruption-Prüfung anschlagen
  • Die Erkennung wird umgangen, indem über dem beschädigten skb zusätzlich ein normales skb freigegeben wird, das den Freilist-Head überschreibt
  • KernelCTF-Entwickler sehen eine mögliche Gegenmaßnahme darin, den Next-Pointer des Freilist-Heads auch beim Free-Zeitpunkt zu prüfen

TLB-Flush und Erkundung von physischem KASLR

  • Wenn Dirty Pagedirectory Seitentabellen auf unerwartete Weise verändert, können veraltete Übersetzungsinformationen im TLB-Cache der CPU verbleiben
  • Der TLB wird geleert, indem aus dem User Space per fork() ein Kindprozess erzeugt wird, der munmap() ausführt und dann schläft
  • Dieses Verfahren funktionierte laut Tests auf AMD-CPUs und in QEMU-VMs zu 100 %
  • Physisches KASLR lässt sich eingrenzen, weil die physische Basis des Kernels an CONFIG_PHYSICAL_START oder CONFIG_PHYSICAL_ALIGN ausgerichtet ist
  • Bei 8 GiB physischem Speicher und 16 MiB Alignment gibt es 512 Kandidaten; mit dem Skript get-sig wird eine Signatur der Kernel-Basis erzeugt und zur Identifikation genutzt

modprobe_path und Erlangung einer Root-Shell

  • Sobald beliebiger physischer Speicher gelesen und geschrieben werden kann, scannt das PoC einen Bereich von rund 80 MiB hinter der Kernel-Basis, um modprobe_path zu finden
  • In typischen Konfigurationen wird nach dem Muster "/sbin/modprobe" mit Null-Padding gesucht und die tatsächliche Variable darüber verifiziert, ob sich Änderungen in /proc/sys/kernel/modprobe widerspiegeln
  • Ist CONFIG_STATIC_USERMODEHELPER aktiviert, wird stattdessen auf die Zeichenkette "/sbin/usermode-helper" gezielt
  • Um eine Root-Shell zu erhalten, wird modprobe_path oder die Zeichenkette des statischen Usermode-Helpers durch einen memfd-Pfad der Form /proc/<pid>/fd/<fd> überschrieben
  • Das Privilege-Escalation-Skript verbindet die File Descriptors des Exploits mit stdin/stdout der Shell, sodass es sowohl auf einem lokalen Terminal als auch mit Reverse Shell funktioniert

Dateilose Ausführung und Aufbau des PoC

  • Das PoC unterstützt fileless execution, also die Ausführung ohne Dateien auf die Platte zu schreiben
  • Ist auf dem Ziel Perl vorhanden, kann das Exploit-Binary per memfd_create() in den Speicher geladen und über /proc/$$/fd/<fd> ausgeführt werden
  • Die Build-Abhängigkeiten sind libnftnl-dev und libmnl-dev
  • Für statische Builds für KernelCTF wurde musl-gcc verwendet, um statisches glibc-Linking und Probleme mit QEMU-AVX512-Opcode zu vermeiden
  • Der Exploit-Quellcode ist auf mehrere Dateien verteilt und setzt aufgrund des Ziels als Standalone-Binary bei Fehlern eher auf crash/exit statt auf die Rückgabe von Error Codes

Stabilität und Grenzen

  • Der Zustand der Pagetables des Exploit-Prozesses kann instabil werden; um Kernel-Instabilität zu verringern, wird der Kindprozess nach Erfolg oder Fehlschlag nicht beendet, sondern im Sleep-Zustand belassen
  • Netzwerkaktivität kann Rauschen in der skb-Freiliste erzeugen und damit die Stabilität beeinträchtigen
  • In SSH- oder Reverse-Shell-Umgebungen wird die stdout-Ausgabe rund um den Double-Free-Zeitpunkt reduziert, um skb-Allokationen/Freigaben durch Netzwerkverkehr zu minimieren
  • In einigen Hardware-Tests stürzte das System nach wenigen Sekunden ab; da auch WiFi-Frames skb verwenden, könnte WiFi-Aktivität Einfluss gehabt haben
  • Wird der WiFi-Adapter im BIOS deaktiviert, funktioniert der Exploit in dieser Umgebung normal

Erkenntnisse aus dem Forschungsprozess

  • Das PoC wurde auf breite Kompatibilität, hohe Stabilität und verdeckte Ausführung hin ausgearbeitet
  • Zusätzlich zu zwei Monaten Entwicklungszeit wurden weitere zwei Monate in Stabilitäts- und Kompatibilitätsverbesserungen investiert
  • Der Exploit selbst hängt nicht stark vom Verhalten des Slab-Allocators ab, sondern konzentriert sich auf breit aktivierte Funktionen wie das IPv4-Subsystem und den virtuellen Speicher
  • Der ursprüngliche Bug setzt zwar unprivilegierte User-Namespaces und nftables voraus, Techniken wie Dirty Pagedirectory und PCP draining können aber auch in anderen realen Exploits eingesetzt werden
  • Die Arbeit bleibt ein Beispiel dafür, wie gleichzeitig das Networking-Subsystem und das Memory-Management-Subsystem des Linux-Kernels angegriffen werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-27
Hacker-News-Kommentare

  • Heute wurde ein Proof-of-Concept-Exploit für CVE-2024-1086 veröffentlicht; er funktioniert unter anderem auf Debian und Ubuntu.
    Betroffen sind Linux-Kernel v5.14 bis v6.6; ob v6.4 bis v6.6 unterstützt werden, hängt von der Kernel-Konfiguration CONFIG_INIT_ON_ALLOC_DEFAULT_ON ab.
    Dieser Bug wurde im Februar 2024 gepatcht, daher sollten Linux-Systeme aktualisiert werden.

    • Der Source ist gut, und die Arbeit ist hervorragend. Ich bin gespannt, wie die größere Reaktion ausfallen wird.
      https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...
    • Wenn man in der Post-Exploitation-Phase KSMA-ähnliche primitive Operationen erhalten hat, frage ich mich, warum weiterhin der modprobe_path-Ansatz genutzt wurde und wegen des dateilosen Ansatzes sogar PID-Bruteforcing eingebaut wurde.
      Ich würde zum Beispiel fragen, warum man sich nicht dafür entschieden hat, Kernel-.text mit kurzer Shellcode zu patchen, um root zu werden und aus dem Namespace auszubrechen.
    • Ich frage mich, welche möglichen Angriffspfade und Auswirkungen diese Schwachstelle hat.
    • Im Artikel steht, die betroffenen Exploit-Versionen seien Linux-Kernel v5.14 bis v6.4, auf der verlinkten Seite steht jedoch v5.14 bis v6.6.
      Allerdings steht dort, dass die gepatchten Branches v5.15.149>, v6.1.76>, v6.6.15> ausgenommen sind.

  • Im Patch steht dieser Satz: „This reverts commit e0abdadcc6e1. [...] Its not clear to me why this commit was made.“
    Ich frage mich, ob jemand die Hintergrundgeschichte dieses Commits recherchiert hat.
    [1] https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...

    • Der ursprüngliche Commit ist inzwischen über 10 Jahre alt, daher ist er wahrscheinlich in der Zeit untergegangen.
      Ich habe alte netdev-Listen durchsucht, aber nichts gefunden; möglicherweise war es ein Patch, der direkt an den Committer Pablo Neira Ayuso geschickt wurde.
      Der ursprüngliche Autor war Patrick McHardy, der inzwischen zur Persona non grata geworden ist, und sofern Pablo sich nicht erinnert oder es in seinen Mails findet, dürfte der genaue Use Case mit einer einfachen Recherche kaum zu klären sein.
    • Der relevante Commit ist folgender: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
      netfilter: nf_tables: accept QUEUE/DROP verdict parameters; damit kann der Userspace bei QUEUE- und DROP-Verdicts eine Queue-Nummer oder einen errno-Code angeben.

  • Dieser Artikel ist auch aus Sicht des Security-Schreibens sehr beeindruckend.
    Beim Schreiben von Security-Blogs ist immer die Frage, „wie viel Hintergrund- und Vorwissen man voraussetzen soll“; eine Balance zu finden, die zugänglich und zugleich machbar zu schreiben ist, ist schwierig.
    Weil gut zuerst die Zielgruppe festgelegt und ausreichend Hintergrund erklärt wurde, habe ich ihn als Material gebookmarkt, das ich angehenden Forschern geben möchte, die ich jedes Jahr treffe.

  • Dieser Exploit hängt vom Zugriff auf unprivilegierte User-Namespaces ab: sysctl kernel.unprivileged_userns_clone = 1
    Das ist der Standardwert der Kernel von Debian/Ubuntu und Arch Linux; wenn man ihn nicht braucht, etwa um Docker-Befehle ohne sudo auszuführen, sollte man ihn besser deaktivieren.

    • Diese Einstellung wird nicht nur von Docker oder Pacman genutzt.
      Auch die Chrome-Sandbox, die etwa von Electron-Apps oder 1Password verwendet wird, hängt damit zusammen; das Sandbox-Hilfsbinary kann auch als setuid-Programm funktionieren.
      Es wäre nicht überraschend, wenn auch Proton künftig anfängt, User-Namespaces zu verwenden; daher ist es auf einem normalen Desktop-Linux möglicherweise besser, sie nicht zu deaktivieren.
      Auf Servern oder speziell gehärteten Linux-Systemen ist es oft keine schlechte Idee, sie abzuschalten.
    • Diese Einstellung ist insofern gut, als sie Menschen ermöglicht, containerartige Dinge ohne root-Rechte auszuführen, aber es ist wirklich bedauerlich, dass sie letztlich schon zu Schwachstellen zur Rechteausweitung auf root geführt hat.
    • Das eigentliche Problem ist nicht diese Einstellung selbst, sondern dass Namespaces ursprünglich ein Mittel sind, um Rechte zu reduzieren.
      Das Problem ist, dass Container, damit sie „einfach funktionieren“, im Netzwerkbereich zahllose Hacks brauchen, und Dockers zentrales Verkaufsargument kommt dem ziemlich nahe, einem diese gefährlichen Hacks abzunehmen.
      Am Ende akzeptiert jede Container-Lösung solche Hacks, und selbst wenn normale Namespace-Funktionen den Zugriff reduzieren, öffnet der Kernel wegen der Netzwerk-Hacks wieder die Tür.
    • In 6.1.65 gibt es diese Option nicht; ich frage mich, ob der Name geändert wurde.

  • Ich verstehe nicht, warum unprivilegierte User-Namespaces standardmäßig aktiviert sind.
    Selbst wenn es innerhalb eines „unprivilegierten“ Namespace läuft: Warum gibt man Nutzern standardmäßig die Möglichkeit, Dinge wie iptables oder mount auszuführen?

    • Unprivilegierte User-Namespaces ermöglichen es Programmen ohne Rechte, eine Sandbox aufzubauen.
      Chrome verwendet zum Beispiel Namespaces, um Prozess-Sandboxing zu implementieren, installiert aber ein setuid-root-Binary, damit es auch ohne unprivilegierte Namespaces funktioniert.
      Da ein setuid-root-Binary selbst ein Sicherheitsrisiko ist, wäre es langfristig wünschenswert, wenn Chrome kein solches Binary mehr installieren müsste.
      Dafür müssten unprivilegierte User-Namespaces jedoch breit verfügbar sein, und Bugs wie dieser verzögern diese Zukunft.
      Außerdem verwenden Programme wie Chrome, die Namespace-basierte Sandboxes aufbauen, häufig auch seccomp, um zu verhindern, dass Code innerhalb der Sandbox ungewöhnliche Kernel-Funktionen wie Namespaces nutzt.
      Auf einem Single-User-Desktop ist der Vorteil, die Trennung zwischen Nutzer und root stark durchzusetzen, nicht besonders groß, und das meiste Interessante ist ohnehin auch vom Benutzerkonto aus zugänglich.
      Eine Sandbox wie die von Chrome ist dagegen für die Desktop-Sicherheit essenziell; daher sehe ich es auf einem Single-User-Desktop eher so, dass aktivierte unprivilegierte User-Namespaces die Gesamtsicherheit erhöhen.
      Multi-User-Systeme sind natürlich eine andere Geschichte.

  • Wenn es diese Bugs nicht ständig gäbe, wären unprivilegierte User-Namespaces eine großartige Sicherheitsfunktion
    Es wäre zum Beispiel gut, wenn Flatpak zum Ausführen für die App-Isolation keine setuid-Binaries auf dem Host benötigen würde

    • Das Problem ist die Philosophie „funktioniert einfach“
      Die meisten Defaults sind nicht sicher und erfordern technisches Wissen sowie Härtungsmaßnahmen

  • Der Commit, der das Problem eingeführt hat: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    In einem verschachtelten switch/case gibt es im Default-Pfad ein return, danach wird aber offenbar Fall-through erwartet; diese Struktur wirkt seltsam

  • Ich frage mich, wie solche Exploits trotz moderner Mitigations wie ASLR möglich sind
    In einer Uni-Vorlesung bekamen wir mehrere Binaries, die auf einer bestimmten Ubuntu-Version laufen sollten, und mussten Bugs wie Use-after-free oder Buffer Overflows finden und ausnutzen; das war wirklich schwierig
    Schon die Schwachstelle zu finden ist schwer, und noch schwerer ist es, präzisen Shellcode zu schreiben, der mit dieser Schwachstelle etwas Nützliches tut
    In den schwierigeren Stufen waren auch Mitigations wie ASLR und Stack Canaries aktiviert, und selbst in der kontrollierten Umgebung für Studierende fühlte es sich nahezu unmöglich an
    Am Ende muss man 1) eine ausnutzbare Schwachstelle entdecken und 2) einen exakten binären Payload finden, der etwas Nützliches tut, ohne das Programm einfach abstürzen zu lassen; in der realen Welt dürfte das noch schwieriger sein, daher frage ich mich, wie das möglich ist
    [0] https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/a...

    • Die Person, die den Kurs belegte, war ein unerfahrener Anfänger und musste in einem 10- bis 15-wöchigen Kurs mehrere Bugs finden und ausnutzen
      Parallel zu anderen Kursen dürfte die verfügbare Zeit pro Bug nur einige Stunden bis wenige Tage betragen haben
      Zerodium zahlt für eine gewöhnliche lokale Rechteausweitung unter Linux 50.000 Dollar; gemessen an den Kosten erfahrener Exploit-Entwickler kann man dafür grob 200 Personenstunden kaufen
      Mit anderen Worten investieren Experten 10- bis 100-mal mehr Zeit als unerfahrene Studierende
      Man kann sich den Unterschied zwischen jemandem vorstellen, der zum ersten Mal in eine Holzwerkstatt geht, und einem Schreiner, zwischen einem Keramik-Anfänger und einem Meister, zwischen einem Erstsemester-Maler und einem professionellen Künstler
      Und dazu kommt noch 10- bis 100-mal mehr Zeitaufwand
      [1] https://zerodium.com/program.html
    • Moderne Mitigations haben Exploits deutlich schwieriger gemacht, aber Forschende finden immer wieder Wege, diese Mitigations zu umgehen
      Es gibt „klassische“ Techniken, um die meisten aktuellen Schutzmechanismen zu umgehen, und wenn nicht, entstehen neue Angriffe oder Bypass-Methoden
      Für das Umgehen von Heap-Schutzmechanismen kann man sich zum Beispiel how2heap ansehen[0]; es gab auch Beispiele für Exploits, die KASLR umgehen[1], und dieser Exploit scheint die dirty pagetable-Technik zu verwenden[2]
      Es ist ein fortlaufendes Katz-und-Maus-Spiel, bei dem Mitigations hinzugefügt werden und Forschende Wege finden, sie zu umgehen
      [0] https://github.com/shellphish/how2heap
      [1] https://www.willsroot.io/2022/12/entrybleed.html
      [2] https://pwning.tech/nftables/#452-the-technique
    • Kurz gesagt: Es gibt Leute, die sehr gut sind, Leute, die Glück haben, und Leute, die sowohl gut sind als auch Glück haben
      Um so etwas zu finden, reicht eine Person aus der letzten Gruppe
      Heutzutage ist es wirklich schwierig, und selbst wenn man die Mitigations abschaltet, ist es weiterhin nicht leicht, Schwachstellen zu finden und Exploits zu schreiben
      Allerdings arbeiten viele der Leute, die solche Schwachstellen finden, in Teams, parallelisieren Fuzzing und können Wissen sowie andere Exploits kombinieren oder chainen
      Die Expertise und das Talent einiger Forschender sind erstaunlich, und in diesem Bereich sind Jahre bis Jahrzehnte an Erfahrung enorm wertvoll
    • In einem ähnlichen Kurs hatte ich ebenfalls die Aufgabe, Binaries zu bekommen und Bugs zu finden; das war ebenfalls schwierig
      Wenn man aber davon ausgeht, dass die heute entdeckten großen Bugs von gut finanzierten Teams oder staatlichen Akteuren gefunden werden, ist es verständlicher, dass sie mit viel Personal und Ressourcen bestehende Mitigations umgehen können
    • Der im Repository verlinkte Blogbeitrag enthält einen eigenen Abschnitt zu KASLR

  • Laut Ubuntu sind alle LTS-Releases betroffen und in den derzeit gepatchten Kerneln behoben: https://ubuntu.com/security/CVE-2024-1086
    Focal ist ab 5.4.0-174.193 behoben, Jammy ab 5.15.0-101.111, Mantic ab 6.5.0-26.26
    Bei Nutzung von Extended Support sind auch Xenial und Bionic enthalten

  • Ich habe es auf einem anfälligen Debian-System ausgeführt: Eine Rechteausweitung gelang zwar nicht, aber beim zweiten Lauf fror das gesamte System ein.
    Der erste Lauf ist einfach fehlgeschlagen, daher lohnt es sich trotzdem definitiv, Zeit in das Patchen zu investieren.

  • Die aktuellen Kernel-Einstellungen lassen sich in Dateien wie /boot/config oder /proc/config.gz überprüfen.