
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.
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:
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).
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.
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:
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.kptr_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.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.
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.
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
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 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.
/proc| Thema | Dokument |
|---|
| KASLR-Einführung | docs/kaslr.md — KASLR-Historie pro Architektur, Standard-Textbasis, vmsplit, FG-KASLR |
| Nutzung & CLI | docs/usage.md — CLI, Ausgabemodi, Explain-Modus, Hardening-Bewertung |
| Ergebnisse interpretieren | docs/limitations.md — was ein negatives oder partielles Ergebnis bedeutet: solide, aber nicht vollständig, und warum ein Fehlschlag keine Sicherheitsgarantie ist |
| Bypass-Techniken | docs/bypass-techniques.md — Dateisystem-Leaks, Seitenkanäle, Syscall-/ioctl-Leaks, schwache Entropie, gepatchte CVEs, beliebiges Lesen |
| Ausnutzung | docs/exploitation.md — wo die KASLR-Umgehung in einen Exploit passt, Control-Flow vs. Data-Only, pwntools-Template, ksymoff |
| Footprint & Erkennung | docs/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 |
| Hilfsprogramme | extra/README.md — die Hilfsskripte in extra/ (Capture/Replay, Soundness-Validierung, Posture-Diff, ksymoff) und wie sie kombiniert werden |
| Architektur & Interna | docs/architecture.md — die Inferenz-Engine, Datenfluss-Nähte, Tagged-Line-Protokoll, regionsübergreifende Ableitung |
| Mitwirken | CONTRIBUTING.md — eine Komponente oder Regel schreiben, Emitter-API, Exit-Codes, Metadaten |
| Testen & CI | docs/testing.md — Host-Tests, Replay-Fixtures, Cross-Arch unter qemu-user, Coverage |
| Reproduzierbarkeit | docs/reproducibility.md — unabhängige Verifikation: auf dem lokalen Kernel, live über Architekturen hinweg oder über den erfassten Korpus |