KASLD: die Kernel-Textbasis unter Linux von einem lokalen Prozess aus eingrenzen
KASLD entzerrt das virtuelle und physische Speicherlayout des Linux-Kernels von einem lokalen Prozess und nutzt dabei alles, was dessen Perspektive, Privilegien, Konfiguration und Beschränkung zulassen.
Auf einen Blick
- Was ist das?
- Eine Rezension des C-Werkzeugs kasld von bcoles: Es fuehrt Dutzende Leak- und Side-Channel-Techniken aus, fusioniert die Belege mit Architekturinvarianten und berichtet das verbleibende KASLR-Fenster als Slot-Anzahl und Entropie-Bits.
- Für wen ist es gedacht?
- kasld passt fuer Sicherheitsteams und Linux-Administratoren, die wissen wollen, wie viel Schutz KASLR auf ihren eigenen Images tatsaechlich laesst, und fuer Kernel-Forscher, die einen strukturierten Werkzeugkasten statt Einzelskripten suchen. Fuer Systeme, deren Hausrecht oder Mandatslage das Ausfuehren von Auslese-Techniken nicht abdeckt, ist es nicht vorgesehen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Kernel-Textbasis eingrenzen: was kasld 0.3.0 meldet
kasld ist ein Werkzeug in C, das das virtuelle und physische Speicher-Layout des Linux-Kernels, vor allem die Kernel-Textbasis, von einem lokalen Prozess aus rekonstruiert. Dazu nutzt es alles, was die Perspektive des Prozesses hergibt: Rechte und Capabilities, die Konfiguration des Systems und jede Container-Beschraenkung. Wo ein Leak oder ein Side-Channel die Basis direkt liefert, meldet kasld sie outright, sonst verengt es die Platzierung auf die kleinste Belegmenge, die die Evidenz zulaesst.
Die Inferenz-Engine verschmilzt Belege aus Dutzenden unabhaengigen Techniken mit den bekannten Invarianten der jeweiligen Architektur. Das Ergebnis ist ein Restfenster, berichtet als Anzahl der ueberlebenden Slots und Entropie-Bits. Das README nennt das eine Obergrenze fuer den Schutz, den KASLR aus dieser Perspektive behaelt, ausdruecklich keine Garantie, dass die Basis unerreichbar ist, und verweist dafuer auf docs/limitations.md.
Ein ehrlicher Satz gehoert zur Einordnung: Auf einem vollstaendig gepatchten modernen Kernel, in dem x86-64-Side-Channels abgefangen sind und kein direkter Kernel-Text-Leak ueberlebt, ist eine volle Rekonstruktion oft unmoeglich, doch die Einschraenkungsmenge ist selten leer. Auf Architekturen ohne KASLR lokalisiert die Engine schlicht die vom Bootloader gewaehlte Ladeadresse.
make und ./build/<arch>/kasld: Build und Schnellstart
Der Schnellstart im README geht von einem Debian-artigen System aus: sudo apt install libc-dev make gcc binutils git, dann git clone https://github.com/bcoles/kasld, cd kasld, make und schliesslich ./build/<arch>/kasld. Der Build laeuft also ohne sonstige Abhaengigkeiten, was die Aufnahme in Test-Images erleichtert.
Das Ergebnis liegt im Verzeichnis build/<arch>/ und ist als selbststaendiges Paket aufgebaut: die Binärdatei kasld plus ein Ordner components/ mit den Leak-Komponenten. Diese Struktur kann ohne Werkzeugkette auf ein Zielsystem kopiert werden, was fuer Pentest-Umgebungen oder Lab-Hardware praktisch ist, wo man nicht erst kompilieren will.
Die Unterstuetzte-Architekturen-Liste ist lang: x86 ab i386 und amd64, ARM in armv6, armv7, armv8 und aarch64, MIPS als mipsbe, mipsel und mips64el, PowerPC in vier Varianten, RISC-V als riscv32 und riscv64, dazu LoongArch (loongarch64) und s390. Die Lizenz ist MIT, die Release-Historie reicht von v0.1.1 im April 2026 bis v0.3.0 vom 18. Juni 2026.
106 von 109 Komponenten: die Ausgabe von kasld im Detail
Der Standard-Textmodus druckt eine antwortorientierte Uebersicht. Das Beispiellauf im README zeigt KASLD 0.3.1-dev auf x86_64 mit Kernel 7.0.0, danach die Zeile Running 106 of 109 components (3 experimental skipped; use -x to enable). Ein Fortschrittsbalken endet bei 39.1 Sekunden, und ein Komponenten-Timeout wird nach 30 Sekunden Timeout abgebrochen. Das zeigt ein wichtiges Detail: Komponenten laufen gestaffelt, und einzelne Haenger kosten standardmaessig bis zu 30 Sekunden.
Die Ergebnistabelle trennt Groesse von Gewissheit. Im Beispiel steht Virtual Image Base mit Certainty guaranteed bei 0xffffffffa2e00000, Slide +0x21e00000, 1 of 505 Slots, Grain 2 MiB. Darunter die Physical Image Base, ebenfalls guaranteed, bei 0x20000. Wer also wissen will, wie viel Unsicherheit uebrig bleibt, liest die Spalte Candidates gegen die Slot-Anzahl.
Fuer die Weiterverarbeitung gibt es fuenf Schalter: -v ergaennt den ausfuehrlichen Ausstoß mit Banner, Systemkonfigurationsblock, Komponenten-Logs, KASLR-Analyse und Speicher-Layout-Karten. -j liefert maschinenlesbares JSON inklusive Komponenten-Records und Haertungsbewertung. -1 druckt eine einzelne, pipe-faehige Zeile, -m formatiert fuer Issue-Tracker, und -H haengt die Haertungsbewertung an Text- oder Markdown-Berichte an. Die vollstaendige CLI samt explain-Modus steht in docs/usage.md.
Vantage-Modell: CAP_SYS_RAWIO gegen kptr_restrict undperf_event_paranoid
Was kasld wiederherstellen kann, haengt laut README an der sogenannten Vantage des Prozesses, und die besteht aus drei unabhaengigen Achsen. Die erste sind Rechte, Gruppen und Capabilities: ein unprivilegierter uid, die Mitgliedschaft in der Gruppe adm, die Kernel-Logs unter /var/log/ freischaltet, ein Container-Task mit einer Zusatz-Capability oder root. Das ist keine Leiter, denn Dateisystemrechte schranken jede Quelle einzeln ab.
Das README nennt ein praegnantes Beispiel: Ein Container mit CAP_SYS_RAWIO ist genau fuer diese Pruefung init-namespace root und kann /proc/kcore lesen, einen Leak, den ein normaler Nutzer nicht erreicht, waehrend Verteilungen darueber differieren, ob /boot/System.map ueberhaupt weltlesbar ist. Die zweite Achse ist die Systemkonfiguration: kptr_restrict, dmesg_restrict, perf_event_paranoid, unprivilegiertes BPF und Kernel-Lockdown. Auch hier gilt Unabhaengigkeit, root kann unter kptr_restrict=2 /proc/kallsyms nicht lesen, waehrend ein gelockertes sysctl einem einfachen Nutzer einen Leak gewaehrt, den ein gehaertetes System verweigert.
Die dritte Achse ist die Einschraenkung: Namespaces oder ein seccomp-Sandbox, die /proc-Orakel verdeckt oder syscalls blockiert. Weil jede Achse jede Quelle einzeln schrankt, ist mehr Privileg keine Obermenge von weniger, und Side-Channels umgehen die sysctls voellig. Die Ausgaben -v, -j und -m berichten die erkannte Vantage inklusive Container, Beschraenkung, lesbarer Orakel und Capability-gestuetzter Leaks.
Haertung pruefen: kernel.unprivileged_bpf_disabled und der Testfall
Fuer Verteidiger ist der konfigurierende Abschnitt des README der nützlichste Teil. Eine gehaertete Konfiguration mit kernel.dmesg_restrict=1, kernel.kptr_restrict=1, kernel.perf_event_paranoid=2 oder hoeher und kernel.unprivileged_bpf_disabled=1 verengt den Pfad ueber die Dateisystem-Orakel. Das README haelt aber ausdruecklich fest, dass das nur eine Achse ist: Side-Channel-, Schwach-Entropie- und Capability-Techniken haengen nicht an diesen sysctls.
Fuer kontrollierte Tests gibt es das Skript extra/weaken-kernel-hardening, das diese Einstellungen voruebergehend lockert und Root verlangt. Der sinnvolle Ablauf ist damit doppelt messbar: Erst der Lauf gegen das gehaertete Ziel, dann der Vergleichslauf mit gelockerten Einstellungen, und der Unterschied zwischen beiden Slot-Counts zeigt, wie viel Schutz die Konfiguration wirklich beisteuert.
Diese Messbarkeit ist der eigentliche Anwendungsfall fuer Betreiber. Statt zu vermuten, dass die gehaertete Konfiguration reicht, liefert ein kasld-Lauf mit -j einen konkreten Restwert in Slots und Entropie-Bits, den man in die Risikoabwaegung uebernehmen kann. Der Beitrag, den eigene Einstellungen leisten, wird damit sichtbar statt behauptet.
docs/limitations.md und docs/footprint.md: was ein kasld-Ergebnis beweist
Die Dokumentationsstruktur des Repositories ist dicht. Der vorgeschlagene Lesepfad fuehrt ueber docs/kaslr.md, eine Einfuehrung mit KASLR-Historie je Architektur, Default-Textbasis, vmsplit und FG-KASLR, zu docs/architecture.md mit dem Abschnitt A leak from end to end und weiter zu docs/limitations.md. Weitere Kapitel behandeln Bypass-Techniken, Ausnutzung inklusive pwntools-Vorlage und ksymoff, sowie docs/footprint.md.
Zwei Punkte aus dieser Struktur verdienen Hervorhebung. Erstens beschreibt limitations.md ein Ergebnis als sound-but-not-complete: Ein negatives oder partielles Resultat beweist keine Sicherheit, weil der Versuch scheitern kann, ohne dass die Basis wirklich geschuetzt ist. Zweitens heisst es im footprint-Kapitel, kasld sei loud by design: Auf einem ueberwachten Host ist das Verhaltensmuster erkennbar, und der Operator zahlt einen OPSEC-Preis, den das Dokument offen adressiert.
Zur Lizenzgeschichte gehoert eine Eigenheit: Einige Leak-Komponenten passen Proof-of-Concept-Code von Dritten an, jede Datei nennt ihre Quelle im Kopf, und THIRD-PARTY-NOTICES.md fuehrt jede Fundstelle samt Lizenz oder Wiederverwendungsgrundlage auf. Die eigentliche MIT-Lizenz erlaubt Nutzung, Kopie, Modifikation, Verbreitung und Verkauf und liefert die Software ohne Gewaehrleistung, was die oben genannten Doku-Limits umso wichtiger macht.
Redaktionelles Fazit
kasld passt fuer Sicherheitsteams und Linux-Administratoren, die wissen wollen, wie viel Schutz KASLR auf ihren eigenen Images tatsaechlich laesst, und fuer Kernel-Forscher, die einen strukturierten Werkzeugkasten statt Einzelskripten suchen. Fuer Systeme, deren Hausrecht oder Mandatslage das Ausfuehren von Auslese-Techniken nicht abdeckt, ist es nicht vorgesehen. Verifizieren Sie vor dem Ernstfall-Einsatz, ob Ihr Ziel mit der Haertungskombination kernel.kptr_restrict=1, kernel.dmesg_restrict=1 und kernel.perf_event_paranoid=2 laeuft, und vergleichen Sie den gemeldeten Slot-Count mit dem, was Ihre Bedrohungsanalyse unterstellt.
Community-Notizen