Schwachstellen und Ausnutzung
Schwachstellen sind Fehler in Software, die ihre Sicherheitsannahmen verletzen; Ausnutzung ist die Kunst, einen solchen Fehler in ein vom Angreifer kontrolliertes Verhalten umzuwandeln, von Datenlecks bis zur vollständigen Codeausführung.
Definition
Eine Schwachstelle ist eine Schwäche in einem System, die ein Angreifer nutzen kann, um dessen Sicherheitsrichtlinien zu verletzen; ein Exploit ist eine Technik oder ein Programm, das eine spezifische Schwachstelle ausnutzt, um unautorisierte Effekte zu erzielen.
Scope
Dieses Thema behandelt die wichtigsten Schwachstellenklassen – Speicherfehler (Pufferüberläufe, Use-after-Free), Injektionen, Ganzzahlfehler und Logikfehler – sowie die Techniken zu deren Ausnutzung, einschließlich Control-Flow Hijacking und Return-Oriented Programming. Es behandelt auch die Mitigationen, die die Kosten der Ausnutzung erhöhen (ASLR, DEP/NX, Stack Canaries, Control-Flow Integrity). Es schließt sichere Entwicklungspraktiken und web-spezifische Schwachstellen aus, die in verwandten Themen behandelt werden.
Core questions
- Welche Kategorien von Softwarefehlern erzeugen ausnutzbare Schwachstellen?
- Wie wird ein Speicherfehler in die Kontrolle über ein Programm umgewandelt?
- Was ist Return-Oriented Programming und warum überwindet es einfache Abwehrmaßnahmen?
- Wie erhöhen Mitigationen wie ASLR, DEP und Stack Canaries die Hürde für die Ausnutzung?
- Warum hält das 'Wettrüsten' zwischen Ausnutzung und Mitigation an?
Key concepts
- Pufferüberlauf
- Use-after-Free
- Ganzzahlüberlauf
- Injektion
- Control-Flow Hijacking
- Return-Oriented Programming
- Shellcode
- ASLR, DEP/NX, Stack Canaries
- Control-Flow Integrity
Key theories
- Control-Flow Hijacking
- Viele Exploits korrumpieren einen Code-Zeiger (wie eine Rücksprungadresse oder einen Funktionszeiger), um die Ausführung auf vom Angreifer gewählten Code umzuleiten, wobei das kanonische Beispiel der Stack-Pufferüberlauf ist, der eine gespeicherte Rücksprungadresse überschreibt.
- Mitigationen und das Wettrüsten der Ausnutzung
- Verteidigungsmaßnahmen wie nicht-ausführbarer Speicher, Address-Space Layout Randomization, Stack Canaries und Control-Flow Integrity blockieren jeweils eine Klasse von Techniken und provozieren in einer fortgesetzten Eskalation neue Angriffe (Return-Oriented Programming, Informationslecks).
Mechanisms
Ein klassischer Stack-Überlauf schreibt über die Grenzen eines Puffers hinaus und überschreibt die gespeicherte Rücksprungadresse, sodass bei der Rückkehr der Funktion die Ausführung zu einem vom Angreifer bereitgestellten Shellcode springt. Mitigationen haben dies unterbrochen: Nicht-ausführbarer Speicher (DEP/NX) verhinderte die Ausführung von injiziertem Code, was zu Return-Oriented Programming führte, das bestehende Codefragmente verkettet; Address-Space Layout Randomization versteckte Zieladressen, was zu Information-Leak-Primitiven führte, um dies zu umgehen. Control-Flow Integrity und speichersichere Sprachen zielen darauf ab, diese Klassen vollständig zu schließen.
Clinical relevance
Ausnutzbare Schwachstellen sind das Rohmaterial realer Angriffe: Speicherfehler machen einen Großteil der kritischen Schwachstellen in wichtigen Browsern und Betriebssystemen aus, Zero-Day-Exploits werden gekauft, verkauft und in Spionage und Kriminalität eingesetzt, und die Disziplin treibt die defensive Entwicklung, verantwortungsvolle Offenlegung, Bug Bounties und den Vorstoß zu speichersicheren Sprachen wie Rust voran.
Evidence & guidelines
Schwachstellenklassen werden in MITREs CWE katalogisiert und einzeln als CVEs mit CVSS-Schweregraden verfolgt. Studien großer Anbieter (Microsoft, Google) berichten, dass etwa 70 % der schwerwiegenden Schwachstellen auf mangelnde Speichersicherheit zurückzuführen sind, was Anleitungen zu speichersicheren Sprachen und die standardmäßige Implementierung von Mitigationen (ASLR, CFI) in modernen Plattformen motiviert.
History
Die Ausnutzung trat mit dem Pufferüberlauf des Morris-Wurms von 1988 ins öffentliche Bewusstsein und wurde 1996 von Aleph Ones 'Smashing the Stack for Fun and Profit' systematisiert. Jede Verteidigung provozierte eine Reaktion: DEP führte zu Return-into-libc und Shachams Return-Oriented Programming (2007); ASLR führte zu Leak-basierten Umgehungen. Die Studie 'Eternal War in Memory' von 2013 beschrieb das anhaltende Wettrüsten, das sowohl neue Mitigationen als auch die Einführung speichersicherer Sprachen weiterhin vorantreibt.
Key figures
- Elias Levy (Aleph One)
- Hovav Shacham
- Dawn Song
- Ross Anderson
- Halvar Flake
Related topics
Seminal works
- aleph1996
- szekeres2013
- anderson2020
Frequently asked questions
- Was ist eine Zero-Day-Schwachstelle?
- Ein Zero-Day ist eine Schwachstelle, die den Verteidigern der Software zum Zeitpunkt ihrer Ausnutzung unbekannt (und ungepatcht) ist, wodurch sie null Tage Zeit haben, sich vorzubereiten. Solche Fehler sind für Angreifer besonders wertvoll, da noch keine Korrektur oder Signatur existiert.
- Warum werden speichersichere Sprachen als Lösung beworben?
- Speichersichere Sprachen (wie Rust) verhindern ganze Klassen von Fehlern – Pufferüberläufe, Use-after-Free – zur Kompilier- oder Laufzeit und eliminieren so die häufigste Ursache schwerwiegender Schwachstellen, anstatt jede einzelne nur schwerer ausnutzbar zu machen.