Zurück zu den Updates
New releaseSep 12, 2026

kasld v0.4.0

KASLD randomisiert das virtuelle und physische Speicherlayout des Linux-Kernels von einem lokalen Prozess aus, wobei es nutzt, was seine Perspektive – Privilegien, Konfiguration und Einschränkungen – zulässt.

Teilen

KASLD logo generated with Copilot (cropped)

Build Status CodeQL Platform: Linux Architectures C99 Release License: MIT

KASLD rekonstruiert das virtuelle und physische Speicherlayout des Linux-Kernels — hauptsächlich die Kernel-Textbasis — aus einem lokalen Prozess heraus und nutzt dabei so viel, wie die Sicht des Prozesses erlaubt: seine Privilegien und Fähigkeiten, die Systemkonfiguration und eine etwaige Container-Eingrenzung. Wo ein Leak oder Seitenkanal es zulässt, rekonstruiert es die Kernel-Textbasis direkt; andernfalls grenzt es sie auf die kleinste Menge von Platzierungen ein, die die verfügbaren Hinweise stützen. Die Inferenz-Engine fusioniert Hinweise aus Dutzenden unabhängiger Techniken mit den bekannten Invarianten der Architektur und grenzt die Platzierung des Kernels auf ein Restfenster ein — angegeben als Anzahl der verbleibenden Slots und Entropie-Bits: eine obere Schranke für den Schutz, den KASLR aus dieser Sicht behält, keine Garantie, dass die Basis außer Reichweite eines Angreifers liegt (siehe docs/limitations.md). Auf einem vollständig gepatchten modernen Kernel — bei dem x86-64-Seitenkanäle entschärft sind und kein direkter Kernel-Text-Leak überlebt — ist eine vollständige Rekonstruktion oft unmöglich, doch die Constraint-Menge ist selten leer. Auf Architekturen ohne KASLR ermittelt die Engine die vom Bootloader gewählte Ladeadresse.

Unterstützt:

  • x86 (i386+, amd64)
  • ARM (armv6, armv7, armv8, aarch64)
  • MIPS (mipsbe, mipsel, mips64el)
  • PowerPC (ppc, ppcle, ppc64, ppc64le)
  • RISC-V (riscv32, riscv64)
  • LoongArch (loongarch64)
  • s390

Schnellstart

sudo apt install libc-dev make gcc binutils git
git clone https://github.com/bcoles/kasld
cd kasld
make
./build/<arch>/kasld

Das Verzeichnis build/<arch>/ ist eigenständig und kann auf ein Zielsystem deployt werden:

build/<arch>/
  kasld              <- dies ausführen
  components/        <- Leak-Komponenten

Eine gehärtete Konfiguration (kernel.dmesg_restrict=1, kernel.kptr_restrict=1, kernel.perf_event_paranoid=2 oder höher, kernel.unprivileged_bpf_disabled=1) verengt den Dateisystem-Orakel-Pfad, ist aber nur eine Achse der Sicht: Seitenkanal-, Weak-Entropy- und durch Fähigkeiten ermöglichte Techniken sind von diesen Sysctls unabhängig. Zum Testen kann das Skript extra/weaken-kernel-hardening diese Einstellungen vorübergehend lockern (erfordert Root).

Beispielausgabe

Der Standard-Textmodus gibt eine antwortorientierte Übersicht aus:

KASLD 0.3.1-dev  --  Kernel Address Space Layout Derandomization
Target: x86_64 / 7.0.0

Running 117 of 120 components (3 experimental skipped; use -x to enable)...
[####################] 100%  117/117  40.9s
1 component timed out after 30s and was killed (prefetch_directmap)

  Quantity             Certainty   Window                                   Candidates      Grain
  -------------------  ----------  ---------------------------------------  --------------  -----
  Virtual Image Base   guaranteed  0xffffffff81000000 - 0xffffffffbd400000      483 of 505  2 MiB
  Virtual Image Base   likely      0xffffffff93400000 slide +0x12400000           1 of 483  2 MiB
  Physical Image Base  guaranteed           0x1000000 -         0x3d400000     474 of 8185  2 MiB
  Physical Image Base  likely               0x1000000 -         0x3c29d000      474 of 474  2 MiB
  Direct Map Base      guaranteed  0xffff800000000000 - 0xffffa4aa80000000           37547  1 GiB
  Vmalloc Base         guaranteed  0xffff898000000000 - 0xffffd6d580000000  79191 of 79191  1 GiB
  Vmemmap Base         guaranteed  0xffffa98040000000 - 0xfffffd0000000000           85504  1 GiB
  Module Region Base   guaranteed  0xffffffffa0000000 - 0xffffffffff000000          389121  4 KiB
  Module Region Base   likely      0xffffffffc0000000 - 0xffffffffc0400000  1025 of 389121  4 KiB
  Paging Level         guaranteed  48                                               1 of 2  -

  Note: physical and virtual text randomize independently

  Note: 1 sub-range excluded from the windows above; the counts
        already reflect them (-v lists the ranges).

Evidence  (1 finding, 2 components)
  Region             Position  Address             Sources
  -----------------  --------  ------------------  -------
  virt kernel image  base      0xffffffff93400000        2

[-v: detailed results, memory map, system info]  [-H: hardening assessment]

-v fügt die vollständige ausführliche Ausgabe hinzu (Banner, Systemkonfigurationsblock, Logs pro Komponente, KASLR-Analyse, Speicherlayout-Karten). -j gibt maschinenlesbares JSON aus — die vollständige strukturierte Ansicht, stets einschließlich der Datensätze pro Komponente und der Hardening-Bewertung. -1 gibt eine einzelne, shell-pipebare Zeile aus. -m formatiert für Issue-Tracker. -H hängt die Hardening-Bewertung an die Text-/Markdown-Berichte an.

Siehe docs/usage.md für die vollständige CLI, Details zu den Ausgabemodi, den Explain-Modus und die Hardening-Bewertung.

Sicht (Vantage)

Was KASLD rekonstruieren kann, hängt von der Sicht des laufenden Prozesses ab — nicht von einer einzelnen Privilegienstufe, sondern von der Kombination dreier unabhängiger Dinge:

  • Privilegien, Gruppen und Fähigkeiten — eine unprivilegierte UID, die Mitgliedschaft in einer Gruppe wie adm (die die Kernel-Logs unter /var/log/ gewährt), ein Container-Task mit einer zusätzlichen Fähigkeit oder Root. Diese bilden keine einzelne Leiter, da Dateisystemberechtigungen jede Quelle unabhängig absichern: Ein Container, dem CAP_SYS_RAWIO gewährt wurde, ist für diese Prüfung Root im Init-Namespace und kann /proc/kcore lesen — ein Leak, das ein gewöhnlicher Benutzer nicht erreichen kann — während Distributionen sich darin unterscheiden, ob eine Datei wie /boot/System.map überhaupt weltweit lesbar ist.
  • Systemkonfigurationkptr_restrict, dmesg_restrict, perf_event_paranoid, unprivilegiertes BPF, Kernel-Lockdown. Die Konfiguration ist unabhängig von Privilegien: Root kann /proc/kallsyms unter kptr_restrict=2 nicht lesen, während ein gelockertes Sysctl oder unprivilegiertes BPF einem einfachen Benutzer ein Leak liefern kann, das ein gehärtetes System verweigern würde.
  • Eingrenzung (Confinement) — ein Namespace- oder Seccomp-Sandbox, der /proc-Orakel maskiert oder Syscalls blockiert und einschränkt, was eine beliebige Privilegienstufe beobachten kann.

Die drei Achsen sichern jede Leak-Quelle unabhängig ab — mehr Privilegien sind also keine Obermenge von weniger: Die Konfiguration kann eine Quelle für Root verweigern, und Seitenkanäle umgehen die Sysctls vollständig. docs/usage.md enthält eine Matrix der Leak-Quellen nach Gate, die zeigt, welche Achse jede Quelle kontrolliert.

KASLD geht standardmäßig von wenigen Privilegien aus und nutzt opportunistisch, was die Sicht gewährt. Das gemeldete garantierte Fenster hängt nie von Privilegien ab: Erhöhter Zugriff oder eine schwache Konfiguration können erweitern, was versucht wird, niemals das solide Layout, das die Hinweise beweisen. Die ausführlichen (-v), JSON- (-j) und Markdown-Ausgaben (-m) melden die erkannte Sicht — Container, Eingrenzung, lesbare Orakel und die durch Fähigkeiten ermöglichten Leaks, die von den aktuellen Fähigkeiten aus erreichbar sind.

Dokumentation

Neu bei KASLD? In dieser Reihenfolge lesen: docs/kaslr.md (was KASLR ist und was es randomisiert) → docs/architecture.md → A leak from end to end (wie KASLD aus einem Leak eine Antwort macht) → docs/limitations.md (was ein Ergebnis beweist und was nicht) → CONTRIBUTING.md (eine Leak-Komponente oder Inferenzregel hinzufügen). Die folgende Tabelle indexiert die Dokumentation nach Thema.

ThemaDokument
KASLR-Einführungdocs/kaslr.md — KASLR-Historie pro Architektur, Standard-Textbasis, vmsplit, FG-KASLR
Nutzung & CLIdocs/usage.md — CLI, Ausgabemodi, Explain-Modus, Hardening-Bewertung
Ergebnisse interpretierendocs/limitations.md — was ein negatives oder partielles Ergebnis bedeutet: solide, aber nicht vollständig, und warum ein Fehlschlag keine Sicherheitsgarantie ist
Bypass-Technikendocs/bypass-techniques.md — Dateisystem-Leaks, Seitenkanäle, Syscall-/ioctl-Leaks, schwache Entropie, gepatchte CVEs, beliebiges Lesen
Ausnutzungdocs/exploitation.md — wo die KASLR-Umgehung in einen Exploit passt, Control-Flow vs. Data-Only, pwntools-Template, ksymoff
Footprint & Erkennungdocs/footprint.md — wie ein Lauf auf einem überwachten Host aussieht: die verhaltensbasierte Signatur zu seiner Erkennung und die OPSEC-Kosten für den Operator; absichtlich auffällig
Hilfsprogrammeextra/README.md — die Hilfsskripte in extra/ (Capture/Replay, Soundness-Validierung, Posture-Diff, ksymoff) und wie sie kombiniert werden
Architektur & Internadocs/architecture.md — die Inferenz-Engine, Datenfluss-Nähte, Tagged-Line-Protokoll, regionsübergreifende Ableitung
MitwirkenCONTRIBUTING.md — eine Komponente oder Regel schreiben, Emitter-API, Exit-Codes, Metadaten
Testen & CIdocs/testing.md — Host-Tests, Replay-Fixtures, Cross-Arch unter qemu-user, Coverage
Reproduzierbarkeitdocs/reproducibility.md — unabhängige Verifikation: auf dem lokalen Kernel, live über Architekturen hinweg oder über den erfassten Korpus

Bauen

Ein Compiler, der das Makro _GNU_SOURCE unterstützt, ist erforderlich, da nicht-portabler Code verwendet wird (MAP_ANONYMOUS, getline(), popen(), …).

make              # build kasld + components
make run          # build and run
make test         # build and run unit tests
make cross        # cross-compile for all supported architectures
make install      # install to /usr/local (PREFIX=/usr/local)
make installcheck # smoke-test the installed bin/kasld + libexec/kasld/
make uninstall    # remove installed files
make clean        # remove build directory
make print-deps   # list build dependencies (libs + per-component flags)
make help         # show all targets and options

make print-deps meldet die erforderliche Toolchain, die beiden optionalen Bibliotheken (pthread, zlib) mit ihrem Auto-Erkennungsergebnis für den aktuellen Compiler sowie die Compile-/Link-Flag-Ausnahmen pro Komponente — genug, um die Control-Datei eines Distributionspakets zu befüllen, ohne die Probe-Logik des Makefiles zu lesen.

make installcheck führt das installierte bin/kasld aus und bestätigt, dass es seine Komponenten über den FHS-Pfad ../libexec/kasld findet — ein Post-Install-Smoke-Test für das Split-Install-Layout, der dasselbe PREFIX/DESTDIR wie make install verwendet (funktioniert also auch gegen ein DESTDIR-Staging-Root in der Paket-CI).

make install installiert außerdem man1-Handbuchseiten für kasld und ksymoff nach <prefix>/share/man/man1/, sodass man kasld und man ksymoff nach der Installation funktionieren.

KASLD kann mit make cross-kompiliert werden, indem der passende Compiler (CC) angegeben wird. Beim Cross-Kompilieren wird automatisch statisch gelinkt:

make CC=aarch64-linux-musl-gcc

Alle unterstützten Cross-Kompilierungsziele bauen (Toolchains müssen im PATH sein):

make cross

Lizenz

KASLD ist MIT-lizenziert (siehe LICENSE). Einige Leak-Komponenten adaptieren Proof-of-Concept-Code Dritter oder implementieren eine Technik, die zuerst von anderen veröffentlicht wurde; jede solche Datei nennt ihren ursprünglichen Autor und ihre Quelle im Header, und THIRD-PARTY-NOTICES.md listet jede mit ihrer Lizenz oder Wiederverwendungsgrundlage auf (Upstream-Lizenz, Genehmigung des Autors oder hier neu implementiertes Technik-/Reproducer-Material).

KASLD zitieren

KASLD ist MIT-lizenziert — eine Namensnennung ist für die Nutzung nicht erforderlich, aber eine Zitation oder ein Link ist überall dort willkommen, wo darauf in Forschung, Tooling, Exploits oder Texten Bezug genommen wird:

KASLD: Kernel Address Space Layout Derandomization, Brendan Coles, https://github.com/bcoles/kasld

BibTeX:

@software{kasld,
  title   = {KASLD: Kernel Address Space Layout Derandomization},
  author  = {Coles, Brendan},
  url     = {https://github.com/bcoles/kasld},
  version = {0.3.0},
  year    = {2026}
}

GitHub zeigt außerdem einen "Cite this repository"-Button aus CITATION.cff an. Für einen unveröffentlichten Build aus master zitiere den spezifischen Commit und das Zugriffsdatum — z. B. bcoles/kasld@<commit> (zugriffen am YYYY-MM-DD) —, da -dev-Versionsstrings nicht eindeutig an einen einzelnen Commit gebunden sind.

Kategorien