Stand: August 2026. Dieser Fachartikel beschreibt ASLR am Beispiel von Linux. Er ist eine technische Einordnung, keine Garantie gegen Speicherfehler und keine Aufforderung, Schutzmechanismen auf produktiven Systemen abzuschalten.
Was ASLR leistet
Address Space Layout Randomization (ASLR) ordnet bei Programmstarts viele virtuelle Adressen anhand zufälliger Offsets an. Ein Angreifer kann dadurch feste Adressen für Bibliotheken, Stack oder ausführbaren Code weniger verlässlich voraussetzen. Die zugrunde liegende Speicherlücke verschwindet jedoch nicht: ASLR erschwert ihre reproduzierbare Ausnutzung und ist deshalb eine zusätzliche Schutzschicht.
Unter Linux betrifft die Randomisierung je nach Kernelkonfiguration unter anderem die Basisadresse von Memory Mappings, Stack und VDSO sowie gemeinsam genutzte Bibliotheken und positionsunabhängige Programme. Der Heap kommt in der umfassenderen Betriebsart hinzu.
Die Linux-Einstellung richtig lesen
Der aktuelle systemweite Modus ist ohne Änderung am System abfragbar:
sysctl kernel.randomize_va_space
Die offizielle Kernel-Dokumentation unterscheidet drei Werte:
0: Adressraum-Randomisierung ist ausgeschaltet.1: Memory-Mapping-Basis, Stack, VDSO, gemeinsam genutzte Bibliotheken und PIE-Programme werden randomisiert.2: Zusätzlich wird der Heap randomisiert.
Welcher Wert voreingestellt ist, hängt auch von der Kernelkonfiguration ab. Für eine Bestandsaufnahme genügt die lesende Abfrage. Ein globales Abschalten ist kein sinnvoller Diagnoseschritt auf einem produktiven System.
Warum PIE zum Hauptprogramm gehört
ASLR kann den Code des Hauptprogramms nur an wechselnden Adressen laden, wenn das Programm positionsunabhängig gebaut wurde. GCC stellt dafür beim Kompilieren -fPIE beziehungsweise -fpie bereit; der Linker erzeugt mit -pie ein Position Independent Executable. Buildsysteme und Distributionen können diese Optionen bereits standardmäßig setzen, deshalb sollte der tatsächlich ausgelieferte Build geprüft werden.
Ein minimales Beispiel für ein eigenes Testprogramm lautet:
cc -fPIE -pie -o demo demo.c
Das ELF-Feld Type: DYN ist ein wichtiger Hinweis auf PIE, bezeichnet allein aber auch gemeinsam genutzte Objekte. Für eine belastbare Einordnung gehören daher Dateityp, ELF-Header und Programm-Header zusammen.
Read-only prüfen
- Systemmodus mit
sysctl kernel.randomize_va_spaceerfassen. - Den eigenen Binärpfad mit
readelf -hW /pfad/zum/programmundreadelf -lW /pfad/zum/programmuntersuchen. - Compiler- und Linkerflags im reproduzierbaren Buildprotokoll prüfen, nicht nur bei einer zufälligen lokalen Binärdatei.
- Bei einem eigenen Testprozess die Speicherabbildung über mehrere Neustarts vergleichen, ohne fremde Prozesse oder produktive Schutzwerte zu verändern.
Die wechselnde Adresse in einer einzelnen Stichprobe beweist noch keine hinreichende Entropie oder Ausnutzungsresistenz. Umgekehrt bedeutet eine stabile Adresse nicht automatisch, dass ASLR insgesamt aus ist: Nicht-PIE-Hauptprogramme und einzelne feste Abbildungen müssen getrennt betrachtet werden.
Verteidigung in der Tiefe
ASLR ist am wirksamsten als Teil einer mehrschichtigen Sicherheitsstrategie. Speicherfehler müssen behoben, Abhängigkeiten aktualisiert und Prozesse mit möglichst wenigen Rechten betrieben werden. Ergänzende Compiler-, Linker- und Laufzeitschutzmechanismen sowie eine begrenzte Offenlegung von Adressinformationen reduzieren weitere Angriffsmöglichkeiten. Informationslecks können die Wirkung von ASLR schwächen; ein grüner Einzelcheck ersetzt deshalb weder Codeanalyse noch Härtungs- und Patchprozesse.
- ASLR und PIE im Zielsystem und im tatsächlich veröffentlichten Build prüfen.
- Schutzwerte nicht für bequeme Fehlersuche global absenken.
- Ergebnisse mit Betriebssystem-, Architektur-, Kernel- und Buildversion dokumentieren.
- Speichersicherheitsfehler als Ursache beheben, nicht nur ihre Ausnutzung erschweren.
Offizielle Primärquellen
Linux-Kernel-Dokumentation zu randomize_va_space ↗
GCC-Dokumentation zu -fpie und -fPIE ↗
GNU-ld-Dokumentation zu -pie ↗
GNU-binutils-Dokumentation zu readelf ↗