Speichersicherheit
Was ist Speichersicherheit?
SpeichersicherheitSpeichersicherheit (Memory Safety) ist die Eigenschaft, dass ein Programm niemals Speicher liest, schreibt oder ausfuehrt, den es nicht legitim allokiert hat, und schaltet damit ganze Schwachstellenklassen aus.
Speichersicherheit umfasst raeumliche Sicherheit (kein Out-of-Bounds-Zugriff), zeitliche Sicherheit (kein Use-after-free oder Double-free), Typsicherheit und Initialisierungs-Sicherheit. C und C++ sind standardmaessig nicht memory safe, weshalb Buffer-Overflows, UAFs und Type Confusion einen Grossteil kritischer CVEs verursachen. Daten von Microsoft, Google Project Zero und der ONCD 2024 (USA) ordnen 60-70 Prozent der schweren Luecken in grossen C/C++-Codebasen Speichersicherheitsfehlern zu. Mitigations (ASLR, DEP, CFI, Sanitizer) erhoehen die Exploit-Kosten; nachhaltig loest nur die Beseitigung der Bugs an der Quelle ueber memory-safe Sprachen oder formal verifizierte Teilmengen das Problem.
● Beispiele
- 01
Ein Out-of-Bounds-Write macht aus einem Heap-Chunk ein vom Angreifer kontrolliertes Objekt.
- 02
Use-after-free gibt ein JavaScript-Objekt frei, dessen Pointer noch im JIT-Cache liegt.
● Häufige Fragen
Was ist Speichersicherheit?
Speichersicherheit (Memory Safety) ist die Eigenschaft, dass ein Programm niemals Speicher liest, schreibt oder ausfuehrt, den es nicht legitim allokiert hat, und schaltet damit ganze Schwachstellenklassen aus. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet Speichersicherheit?
Speichersicherheit (Memory Safety) ist die Eigenschaft, dass ein Programm niemals Speicher liest, schreibt oder ausfuehrt, den es nicht legitim allokiert hat, und schaltet damit ganze Schwachstellenklassen aus.
Wie funktioniert Speichersicherheit?
Speichersicherheit umfasst raeumliche Sicherheit (kein Out-of-Bounds-Zugriff), zeitliche Sicherheit (kein Use-after-free oder Double-free), Typsicherheit und Initialisierungs-Sicherheit. C und C++ sind standardmaessig nicht memory safe, weshalb Buffer-Overflows, UAFs und Type Confusion einen Grossteil kritischer CVEs verursachen. Daten von Microsoft, Google Project Zero und der ONCD 2024 (USA) ordnen 60-70 Prozent der schweren Luecken in grossen C/C++-Codebasen Speichersicherheitsfehlern zu. Mitigations (ASLR, DEP, CFI, Sanitizer) erhoehen die Exploit-Kosten; nachhaltig loest nur die Beseitigung der Bugs an der Quelle ueber memory-safe Sprachen oder formal verifizierte Teilmengen das Problem.
Wie schützt man sich gegen Speichersicherheit?
Schutzmaßnahmen gegen Speichersicherheit kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Speichersicherheit?
Übliche alternative Bezeichnungen: Memory-Safety-Bugs.
● Verwandte Begriffe
- appsec№ 671
Memory-Safe Sprachen
Memory-safe Sprachen wie Rust, Go, Swift, Java und C# verhindern die raeumlichen und zeitlichen Speicherfehler, die die meisten ausnutzbaren Luecken in C und C++ ausmachen.
- appsec№ 953
Sicherheitseigenschaften von Rust
Rust erzwingt Speicher- und Thread-Sicherheit zur Compile-Zeit ueber Ownership, Borrowing und Lifetimes und beseitigt UAF und Data Races ohne Garbage Collector.
- appsec№ 217
Control-Flow Integrity
Control-Flow Integrity (CFI) beschraenkt indirekte Aufrufe und Returns auf einen vorab berechneten Satz legitimer Ziele und blockiert ROP- bzw. JOP-Angriffe.
- appsec№ 064
ASLR
Address Space Layout Randomization platziert Code, Stacks, Heaps und Bibliotheken bei jedem Programmstart zufaellig im Speicher, sodass Angreifer Zieladressen nicht vorhersagen koennen.
- appsec№ 303
DEP
Data Execution Prevention (auch NX oder W^X) markiert Speicherseiten als nicht ausfuehrbar, sodass Angreifer keinen in Stack oder Heap eingeschleusten Shellcode starten koennen.
- appsec№ 925
Return-Oriented Programming
Return-Oriented Programming (ROP) ist eine Exploit-Technik des Code-Reuse, die kurze, mit RET endende Instruktionsfolgen verkettet, um beliebige Berechnungen ohne neuen Code auszufuehren.
● Siehe auch
- № 1095Stack Canary
- № 1028Shadow Stack
- № 581KASLR
- № 1058SMEP / SMAP