Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Upcoming SlideShare
Loading in...5
×
 

Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista

on

  • 3,173 views

Hierbei handelt es sich um eine Studienarbeit, deren Thema Stack- und Heap-Overflows unter Windows XP und Windows Vista ist. Zur Einführung ist ein umfangreiches Grundlagenkapitel enthalten, dass die ...

Hierbei handelt es sich um eine Studienarbeit, deren Thema Stack- und Heap-Overflows unter Windows XP und Windows Vista ist. Zur Einführung ist ein umfangreiches Grundlagenkapitel enthalten, dass die generelle Funktionsweise von Overflows und Code-Injection unter Windows beschreibt. Eine Besonderheit sind hierbei die ausführlich auf Kompatibilität getesteten Demo-Programme mit Quellcode.
Um Experimentierfreudigen einen möglichst leichten Einstieg zu geben, wird in den Quellcode-Beschreibungen auf Sicherheitsoptimierungen unterschiedlicher Compilerversionen eingegangen.

Statistics

Views

Total Views
3,173
Views on SlideShare
3,156
Embed Views
17

Actions

Likes
1
Downloads
30
Comments
0

3 Embeds 17

http://hohenbichler.blogspot.de 11
http://hohenbichler.blogspot.com 4
http://hohenbichler.blogspot.ch 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Document Transcript

  • StudienarbeitStack- und Heap-Overflow-Schutz beiWindows XP und Windows Vista Fachbereich InformationstechnikStudiengang Softwaretechnik und Medieninformatik Semester: SWT6 Name: Johannes Hohenbichler Datum: 20.08.2008  Version: 1.03 Betreuer: Dominik Schoop
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista I InhaltsverzeichnisI Inhaltsverzeichnis ......................................................................................................................... 1-2II Abbildungsverzeichnis .................................................................................................................. 1-4III Abkürzungsverzeichnis ................................................................................................................. 1-5IV Toolsverzeichnis ........................................................................................................................... 1-6V Besondere Darstellungsformen.................................................................................................... 1-71 Überblick ...................................................................................................................................... 1-82 Grundlagen – Systemarchitektur................................................................................................ 2-10 2.1 Speicherorganisation .......................................................................................................... 2-10 2.1.1 Virtueller Speicher ...................................................................................................... 2-10 2.1.2 Systemfunktionen....................................................................................................... 2-11 2.1.3 Speichersegmente ...................................................................................................... 2-13 2.1.4 Big- und Little-Endian ................................................................................................. 2-153 Grundlagen – Buffer Overflows .................................................................................................. 3-16 3.1 Buffer Overflows ................................................................................................................ 3-16 3.1.1 Off-By-One Buffer Overflows ..................................................................................... 3-17 3.1.2 Mit Buffer Overflows den Kontrollfluss ändern ......................................................... 3-18 3.1.3 Ausführen von beliebigem Code ................................................................................ 3-21 3.1.4 Klassische Stack-basierende Angriffe ......................................................................... 3-22 3.1.5 Exception Handler-basierende Angriffe ..................................................................... 3-25 3.1.6 Heap-basierende Angriffe .......................................................................................... 3-27 3.2 Shellcode und Payload ....................................................................................................... 3-29 3.2.1 Anforderungen an Shellcode ...................................................................................... 3-29 3.2.2 Besonderheiten von Windows-Shellcode .................................................................. 3-30 3.2.3 Was möglich ist........................................................................................................... 3-30 3.2.4 Abstraktes Beispiel: Portbind Shellcode für Windows ............................................... 3-314 Das Sicherheits-Ensemble von Windows und seine Schwachstellen ........................................ 4-32 4.1 Das Windows-Zwei-Schichten-Modell................................................................................ 4-32 4.2 Zugriffsrechte, Authentifizierung und Access Token.......................................................... 4-33 4.2.1 Rechte von Prozessen unter Windows ....................................................................... 4-34 4.2.2 Windows Service Hardening....................................................................................... 4-35 4.2.3 Rechte von Prozessen unter Windows Vista: UAC ..................................................... 4-35 Seite - 2 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista 4.3 PatchGuard ......................................................................................................................... 4-37 4.4 Process Exection Block (PEB) Randomization..................................................................... 4-37 4.5 Heap-Schutz........................................................................................................................ 4-38 4.6 Visual Studio 2005 - Der "Windows-Compiler" .................................................................. 4-40 4.6.1 Standard Annotation Language (SAL) ......................................................................... 4-40 4.6.2 Optimierte Anordnung von Stack-Elementen (O2) .................................................... 4-42 4.6.3 Puffer-Sicherheitsüberprüfung (GS) ........................................................................... 4-43 4.6.4 Sichere Ausnahmebehandlung (SafeSEH) .................................................................. 4-47 4.6.5 Data Execution Prevention (DEP) ............................................................................... 4-48 4.6.6 Address Space Layout Randomization (ASLR) ............................................................ 4-51 4.7 Abschließender Vergleich: XP gegenüber Vista ................................................................. 4-525 Fazit ............................................................................................................................................ 5-54A Literaturverzeichnis .................................................................................................................... 5-56B Quellcode ................................................................................................................................... 5-60 Seite - 3 - View slide
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista II AbbildungsverzeichnisAbbildung 2-1: 32-Bit-Windows Standard-Adresslayout nach [ 2 ] .................................................. 2-11Abbildung 2-2: Prinzipielles Windows Prozess-Speicher-Layout nach [ 3 S. 182 ] und [ 4 S. 397 ] .. 2-13Abbildung 2-3: Big-Endian im Speicher .............................................................................................. 2-15Abbildung 2-4: Little-Endian im Speicher ........................................................................................... 2-15Abbildung 3-1: Die Buffer buf0 und buf1 im Speicher ....................................................................... 3-18Abbildung 3-2: Buffer Overflow von password_buffer in auth_flag .................................................. 3-21Abbildung 3-3: Beispielhaftes Stackframe unter Windows allgemein ............................................... 3-22Abbildung 3-4: Angriffsvektor ............................................................................................................ 3-23Abbildung 3-5: Beispielhaftes Stackframe unter Verwendung von SEH [ 13 ] .................................. 3-27Abbildung 4-1: Windows-Zwei-Schichten-Modell [ 4 ] ...................................................................... 4-33Abbildung 4-2: Optimierte Anordnung von Stack-Elementen bei VS 2003 ....................................... 4-43Abbildung 4-3: Beispielhaftes Stacklayout unter Verwendung von /GS bei VS 2005 [ 32 ] .............. 4-45 Seite - 4 - View slide
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista III AbkürzungsverzeichnisASLR Address Space Layout RandomizationBS BetriebssystemDACL Discretionary Access Control ListDEP Data Execution Protection, auch bekannt als NXDoS Denial of ServiceDll Dynamic Link LibraryEH Exception HandlerGByte GigabyteIE Internet ExplorerLSA Local Security Authority Subsystem ServiceNX No eXecute, auch bekannt als DEPRET ReturnaddressSAL Standard Annotation LanguageSEH Structured Exception HandlingSFP Saved Frame PointerSID Security IdentifierVS Visual Studio Seite - 5 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista IV ToolsverzeichnisProgramm BezugsmöglichkeitWindows power shell http://www.microsoft.com/windowsserver2003/technologies/management/power shell/default.mspxStrawberry Perl http://strawberryperl.com/Process Explorer http://technet.microsoft.com/de-de/sysinternals/default(en-us).aspxDisplay Heap Windows Server 2003 Resource Kit Tools http://support.microsoft.com/kb/168609/deGlobal Flags Debugging Tools for Windows http://www.microsoft.com/whdc/devtools/debugging/default.mspx Seite - 6 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista V Besondere DarstellungsformenIn dieser Arbeit kommen im Wesentlichen vier spezielle Gestaltungselemente zur Anwendung1. Begriffserklärungen und Hinweise sind in einer Box der folgenden Art untergebracht Begriffserklärungen und Hinweise Begriff: Beschreibung oder Definition des Begriffs bzw. Hinweistext2. KommandosKommandos die auf der Kommandozeile eingegeben werden (cmd.exe)sind grau hinterlegt3. ProgrammausgabenProgrammausgabensind orange hinterlegt4. Quellcode / Ausschnitte aus DateienAuszüge aus Quellcode / Konfigurationsdateinsind hellblau hinterlegt Seite - 7 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista1 ÜberblickAusgangssituationIn der Vergangenheit waren Buffer-Overflows eines der Hauptsicherheitsrisiken für Software. In denletzten Jahren haben Softwarehersteller an diesem Problem intensiv gearbeitet und den Schutz starkerhöhen können. Das beweisen nicht zuletzt CVE1-Statistiken, die Windows Vista für das Jahr 2008bis zum Erscheinen dies Dokuments, in dem Monat Juni, nur eine einzige Schwachstellebescheinigen, die direkt auf Buffer-Overflows zurückzuführen ist. [ 1 ]Ziel dieser ArbeitDas Ziel dieser Arbeit ist es, einen Überblick zu schaffen, welche Mechanismen die BetriebssystemeWindows XP und Windows Vista zur Vermeidung und zur Schadensbegrenzung von Buffer Overflowsbieten. Dabei wird auf die Schwachstellen der vorhandenen Mechanismen eingegangen und eswerden Wege aufgezeigt, wie sich diese Schwachstellen praktisch auszunutzen lassen. Außerdem hates diese Arbeit zum Ziel, die Neuerungen von Windows Vista, dem noch weiter verbreitetenWindows XP gegenüber zu stellen und so den sicherheitstechnischen Mehrwert von Windows Vistadarzulegen.An wen richtet sich diese ArbeitDiese Arbeit richtet sich an alle Leser, die an der definierten Zielsetzung interessiert sind. Zumvollständigen Verständnis werden jedoch Grundkenntnisse der Programmiersprachen c und x86Assembler vorausgesetzt. Für Buffer Overflows besonders relevante Punkte sind jedoch grundliegendbeschrieben, so dass die Arbeit auch für Leser ohne Vorkenntnisse aus dem Themengebiet "Buffer-Overflows" verständlich sein sollte.Gliederung dieser ArbeitDie einzelnen Kapitel dieser Arbeit können für sich selektiv gelesen werden. Die beidenGrundlagenkapitel(Kapitel 2, 3) bauen jedoch aufeinander auf und sollten von Beginn bis Endegelesen werden. Zudem wird im Hauptkapitel(Kapitel 4) auf die Angriffsmöglichkeiten bezuggenommen, die im Grundlagenkapitel "Buffer Overflows" erklärt werden.In dem Kapitel 2 werden einige, für Buffer Overflows wichtige, Grundlagen zur Systemarchitekturvorgestellt. Der Fokus liegt hierbei speziell auf Eigenheiten des NT-Kerns der BetriebssystemfamilieMicrosoft Windows.1 National Vulnerability Database: http://nvd.nist.gov/ Seite - 8 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaIn dem Kapitel 3 wird eine Einführung in das Thema Buffer Overflows gegeben und es werdeneinzelne Codestücke präsentiert. Um die Übersichtlichkeit an dieser Stelle nicht unnötig zubeeinträchtigen sind die vollständigen Programme in einem Zip-Archiv(Kapitel B) zu finden. Ebenfallsim Kapitel B, finden sich Hinweise zum Übersetzen der jeweiligen Programme mit dem Compiler derEntwicklungsumgebung Visual Studio 2003 / 2005. Ziel dieses Kapitels ist es, die grundliegendenKonzepte von Buffer Overflows zu umreißen und einige windows-spezifische Angriffe zu erläutern.Das Hauptkapitel dieser Arbeit beschäftigt sich im Detail mit den verschiedenen Schutzmaßnahmenvon Windows XP und Vista. Hierbei wird vor allem auf den effektiven Nutzen der einzelnenMaßnahmen eingegangen. In diesem Zusammenhang werden Implementierungs- undDesignschwachstellen aufgezeigt und objektiv beurteilt. Dabei wird auf die im Kapitel 3 vorgestelltenAngriffe eingegangen und es wird geklärt, warum die Angriffe noch, oder nicht mehr, funktionieren.Abschließend folg eine Zusammenfassung der wesentlichen Erkenntnisse der wesentlichenErkenntnisse und kritischen Blick auf die derzeitigen Entwicklungen. Seite - 9 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista2 Grundlagen – SystemarchitekturIn diesem Kapitel werden Grundlagen aus den Bereichen Betriebssystem- und Rechnerarchitekturvorgestellt, die für ein fundiertes Verständnis von Buffer Overflows benötigt werden. Dabei wirdspeziell auf Eigenheiten des NT-Kernels, der Betriebssystemfamilie Microsoft Windows, eingegangen.2.1 SpeicherorganisationIn diesem Abschnitt wird die Speicherorganisation von Windows XP und Windows Vista grundliegenderläutert um ein eine Basis für das Verständnis, der in Kapitel 3 beschriebenen Angriffstechniken, zuschaffen.2.1.1 Virtueller SpeicherBei 32-Bit-Windows-Systemen steht einer Anwendung theoretisch der maximal adressierbareSpeicher von 0x00000000 bis 0xFFFFFFFF zur Verfügung, was einer Größe von 2³² Byte = 4 GByteentspricht. Dabei ist die kleinste adressierbare Einheit ein Byte groß.Diese 4 GByte teilt Windows in zwei Hälften. Den höherwertigen Bereich verwendet es fürBetriebssystemfunktionen und den niederwertigen Bereich für das Programm selbst. Die Trennungist normalerweise, wie in der Abbildung 2-1 zu sehen ist, in der Mitte des Gesamtspeichersvorgenommen. Dank dem Konzept des virtuellen Adressraums, ist es dabei nicht wichtig, welcheMenge an Arbeitsspeicher das System tatsächlich benötigt. Mit Hilfe der Hardware, zurAdressvirtualisierung, kann das Betriebssystem die Umsetzung von physikalischen in virtuelleAdressen erledigen, ohne dass sich ein laufendes Programm darum bemühen muss. Dabei kümmertsich das Betriebssystem automatisch um das Ein- und Auslagern von Speicher. Seite - 10 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Hinweis 0000000h (Kleine Adressen) Unter 32-Bit-Windows lässt sich die Aufteilung auch mittels einer 00000000h Benutzermodus- Bootoption in das Verhältnis 3GB Prozesse (2GB) zu 1GB (Programmspeicher zu 7FFFFFFFh Systemspeicher) ändern. Unter 80000000h Systemspeicher 64-Bit-Windows-Varianten ist die (2GB) Speicheraufteilung nahezu 50% FFFFFFFFh zu 50% [ 2 S. 14ff ] . FFFFFFFFh (Große Adressen) Außerdem gibt es die Address Windowing Extensions (AWE) mit deren Hilfe sich der virtuelleAbbildung 2-1: 32-Bit-Windows Standard-Adresslayoutnach [ 2 ] Speicher vergrößern lässt [ 2 S. 383ff ]2.1.2 SystemfunktionenIm Zusammenhang mit Buffer Overflows ist weniger die im letzen Kapitel vorgestellteSpeicheraufteilung interessant, sondern viel mehr die Art wie auf Systemfunktionen zugegriffen wird.Im normalen Programmbetrieb werden alle benötigten Systemfunktionen, wie beispielsweisesleep(), in den virtuellen Adressbereich der Anwendung eingeblendet. Beim Übersetzen desQuellcodes erzeugt der Compiler automatisch die Befehle zum Laden der nötigen Systemfunktionen.Die Adressen an denen die verschiedenen Systemfunktionen zu finden sind, sind innerhalb einesSystems normalerweise immer gleich. Unterschiede bezüglich der Funktionsadressen gibt es lediglichzwischen den einzelnen Windows-Versionen sowie zwischen den verschiedenen Service-Packs. Einewirkliche Ausnahme entsteht allerdings durch Address Space Layout Randomization (ASLR), auf das indem Kapitel 4.6.4 eingegangen wird.Ein Beispiel:Mit dem Programm dumpbin.exe, das Teil von Visual Studio 2005 ist, lässt sich die Basis-Adresse desWindows-Kernels ermitteln:PS C:WINDOWSsystem32> dumpbin /headers kernel32.dll | select-string -pattern "image base" 7C800000 image base (7C800000 to 7C906FFF)Um nun beispielsweise die Absolute Adresse der Sleep-Funktion zu ermitteln muss noch die relativeAdresse, ausgehend von der Basis-Adresse, ermittelt werden: Seite - 11 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaPS C:WINDOWSsystem32> dumpbin /all kernel32.dll | select-string -pattern"sleep" 7C8087E0: 73 6F 75 72 63 65 00 53 6C 65 65 70 00 53 6C 65 source.Sleep.Sle 831 33E 00002442 Sleep 832 33F 0000239C SleepExAus der Basis-Adresse und der relativen Adresse ergibt sich die absolute Adresse der Funktionsleep()7c800000h + 00002442h = 7c802442hWie bereits erwähnt ist diese Adresse bei jedem Programmstart, unter Berücksichtigung der obengenannten Ausnahmen, gleich. Tools-Hinweis Die obigen Kommandos wurden nicht in der normalen Eingabeaufforderung, sondern in der kostenlos über Microsoft erhältlichen Powershell, ausgeführt. Der Grund hierfür ist, dass in der Powershell die Funktion select-string() zur Verfügung steht. Bezugsmöglichkeiten: siehe Toolsverzeichnis Seite - 12 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista2.1.3 SpeichersegmenteDer einem Prozess zur Verfügung stehende virtuelle Speicher, teilt sich wie in Abbildung 2-2 zu sehenist, in verschiedene Segmente auf. Wichtig sind hierbei vor allem die relative Position der Segmentezueinander, sowie die Richtung des Schreibzugriffs. Der Schreibzugriff erfolgt immer von einerBasisadresse in Richtung der höherwertigen Adressen. Prozess-Speicher Beispielhaftes Stackframe 0000000h (Kleine Adressen) Gespeicherte Register der Heap aufrufenden Funktion Lokale Variablen Stack Frame Pointer (SFP) Schreibrichtung Stack Return Adresse (RET) Parameter .TXT .DATA Heap entspricht einer Dynamischen .BSS Erweiterung des BSS-Segments (langlebige Daten) Stack Registerinhalte FFFFFFFFh Systemspeicher lokale Variablen (Große Adressen) Funktionsparameter (kurzlebige Daten) .TXT Programmkode .DATA Initialisierte globale und statische Variablen .BSS Nicht initialisierte globale und statische Variablen WachstumsrichtungAbbildung 2-2: Prinzipielles Windows Prozess-Speicher-Layout nach [ 3 S. 182 ] und [ 4 S. 397 ] Seite - 13 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaStackDer Stack ist das Speichersegment, das zum Ablegen kurzlebiger Daten dient. So werden auf demStack beispielsweise lokale Variablen und Funktionsparameter abgelegt.In Abbildung 2-2 ist, auf der rechten Seite, ein typisches Stackframe abgebildet. Anhand der Pfeile,die die Wachstumsrichtung angeben, lässt sich erkennen, dass der Stack von großen Adressen inRichtung kleiner Adressen wächst.Das Prinzip eines Stacks, oder auch Stapelspeicher genannt, ist folgendes: 1. Sollen neue, kurzlebige Daten zwischengespeichert werden, so werden diese auf die bereits auf dem Stack liegenden Daten von oben aufgelegt. Die Operation zum Auflegen neuer Daten nennt sich "push". 2. Werden die auf dem Stack gelegten Daten zur Verarbeitung benötigt oder muss der Stack aufgeräumt werden, so wird von oben, Stück für Stück, abgebaut. Die Operation zum Herunternehmen von vorhandenen Daten nennt sich "pop".Wenn innerhalb eines Prozesses eine Funktion aufgerufen wird, so werden die benötigten Daten, wiein der Abbildung 2-2 auf der rechten Seite zu sehen ist, auf dem Stack abgelegt (push). Ist dieFunktion beendet, so werden die Daten in umgekehrter Reihenfolge wieder vom Stack genommen(pop).Der Teil des Maschinencodes, der ein Stackframe aufbaut, nennt sich Prolog und der abbauende Teilnennt sich Epilog.Genauere Informationen zur Funktionsweise des Stacks können in [ 5 ] gefunden werden.HeapDer Heap ist der dynamische Speicherbereich eines Prozesses. Er kann dynamisch in seiner Größewachsen, somit kann der Prozess dynamisch Speicher anfordern und freigeben.Der Heap ist in Abbildung 2-2 im Bereich der niedrigen Speicheradressen zu sehen, was für Windowstypisch ist. Außerdem ist in der Abbildung 2-2 dargestellt, dass der Heap in Richtung großer Adressenwächst.Inhaltlich gesehen werden auf dem Heap, verglichen mit dem Stack, langlebigere Daten abgelegt.Ein Prozess hat typischer Weise mehrere Heaps. Ein neuer Heap kann z. B. mit der Windows-API-Funktion HeapCreate() angefordert und mit HeapDestroy() wieder freigegeben werden. DasAnfordern eines Speicherbereiches erfolgt anschließend mit HeapAlloc() und wird analog mitHeapFree() wieder freigegeben. Bei Verwendung des c++-Operators new, wird automatischSpeicher von dem Standard-Heap des Prozesses angefordert. Seite - 14 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaWie bereits angedeutet, hat der Programmierer die Wahl. Entweder er verwendet die von derWindows-API bereitgestellten Funktionen für das Heap-Management, oder er verwendet seineeigene Heap-Verwaltung. [ 6 ]Die von Windows standardmäßig verwendete Heap-Verwaltung organisiert den Speicher in einerReihe unterschiedlicher Listen, die zusammen den gesamten Heap beschreiben. Dabei gibt es unteranderem, eine Liste für noch freie, kleine Speicherblöcke mit Größe 4KByte und eine separatgeführte Liste, die alle belegten Blöcke enthält. Zudem werden temporären Listen erstellt, die derGeschwindigkeitserhöhung dienen. [ 7 ] [ 8 ] [ 9 ]2.1.4 Big- und Little-EndianAls Big- und Little-Endian, werden zwei verschiedene Darstellungsformen von Werten, im Speicherbezeichnet.Beispiel: Darstellung der Speicher-Adresse AABBCCDD Hex = 2864434397 Dez im SpeicherBig-Endian: Das höchstwertige Paar steht ganz links, wie in Abbildung 2-3 zu sehen. Big-Endian AA BB CC DD 00000000h FFFFFFFFhAbbildung 2-3: Big-Endian im SpeicherLittle-Endian: Das höchstwertige Paar steht ganz rechts, wie in Abbildung 2-4 zu sehen. Little-Endian DD CC BB AA 00000000h FFFFFFFFhAbbildung 2-4: Little-Endian im Speicher Seite - 15 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista3 Grundlagen – Buffer OverflowsZiel dieses Kapitel ist es, dem Leser die Grundkonzepte von Buffer Overflows zu vermitteln um so dievon Windows XP und Windows Vista verwendeten Schutzmechanismen besser beurteilen zu können.Im Folgenden sind immer nur die unmittelbar relevanten Codeabschnitte gelistet. Die vollständigenProgramme mit Hinweisen zum Übersetzen und zugehöriger Programmausgaben sind im Anhang zufinden. Wichtiger Hinweis für Selbstversuche Mit Visual Studio 2005 lassen sich die meisten Beispielprogramme nicht ohne weiteres mit den erwarteten Ergebnissen übersetzen. Der Grund hierfür sind Optimierungen und Schutzmechanismen, die der Visual Studio 2005 Compiler verwendet. Hinweise zum „richtigen“ Übersetzen, sowie die vollständigen Programme finden sich jeweils im Anhang3.1 Buffer OverflowsIm Kontext der Programmiersprache c, ist ein Buffer ein zusammenhängender Speicherbereich, derDaten desselben Typs beinhaltet. In c werden Buffer häufig auch als Arrays bezeichnet.Ein primitiver Buffer kann in c beispielsweise folgende Form haben:char buf0[4] = "ABC0";In diesem Fall ist der Buffer 4 Byte groß und ist ein String-Buffer. Dabei dient das letzte Byte zurTerminierung des Strings.Ein Buffer Overflow, oder auch Puffer-Überlauf, passiert demnach, wenn die Grenzen desvorgesehenen Speicherbereichs überschritten werden.Die Folgen für das Gesamtsystem können dabei sehr unterschiedlich ausfallen.So zeigt sich die gefährliche Seite von Buffer Overflows, wenn es dem Angreifer möglich istbeliebigen Code einzuschleusen und seine Ausführung zu erreichen. In diesem Fall stehen demAngreifer nahezu unbegrenzte Möglichkeiten zur Verfügung. Von einem primitiven Beenden derverwundbaren Software bis hin zum Erstellen von Benutzerkonten oder dem installieren eines Root-Kits (Details zu Angriffen dieser Art in dem Kapitel 3.1.4). Seite - 16 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaBei weniger kritischen Programmierfehlern kann es zu inkonsistenten Daten kommen die nichtzwangsläufige einen Programmabsturz nach sich ziehen müssen und somit lange unentdeckt bleibenkönnen. Damit beeinträchtigen diese Fehler zwar den Nutzen der Software, dieAngriffsmöglichkeiten können aber, wie das Beispiel im nächsten Abschnitt zeigt, recht beschränktsein.3.1.1 Off-By-One Buffer OverflowsEin klassischer Buffer Overflow im Zusammenhang mit c-Strings ist der "Off-By-One"-Fehler. Dabeivergisst der Programmierer entweder den bereits erwähnten String-Terminator mitzuzählen, oder erist bei der indexzählweise der Arrays unaufmerksam.Mit folgenden Programmausschnitten sollen die Folgen eines Off-By-One Overflows verdeutlichtwerden. Das vollständige Programm mit Compiler-Optionen und vollständiger Ausgabe sind imQuellcode-Archiv zu finden (Kapitel B). Quellcode: Kapitel-3-1-1_off-by-oneoff-by-one.c//gekürzt...char buf0[] = "1234";char buf1[4] = "ABC0";strcpy(buf1,buf0);Führt man das vollständige Programm aus, so erhält man folgende Ausgabe~~~ vorher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Adresse von buf0: 0012FF68 sizeof(buf0): 5 ByteAdresse von buf1: 0012FF64 sizeof(buf1): 4 Bytebuf0 1234buf1 ABC~~~ nachher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~buf0buf1 1234Betrachtet man diese Programmausgabe genauer, so fällt auf, dass der Buffer buf1 zwar dengewünschten Inhalt erhalten hat, buf0 seinen Inhalt aber offenbar verloren hat.Was hier passiert ist schnell erklärt: Es kommt zu einen Buffer Overflow, weil der Programmierervergessen hat, dass der Compiler an der Stelle char buf0[] = "1234"; automatisch ein 5-Bytegroßes, null-terminiertes String-Array erstellt.Deshalb überschreibt strcpy() mit dem 0 den ersten Teil des Buffers buf0, der nach buf1 imSpeicher liegt. Die Abbildung 3-1 soll diesen Vorgang verdeutlichen.Hinweis zum Speicherlayout: Die Anordnung von Variablen im Speicher wird immer zum Zeitpunktdes Übersetzens festgelegt und wird von dem Compiler entschieden. Der Compiler folgt beimErstellen des Speicherlayouts zwar festen Regeln, eine feste Beziehung zwischen der Reihenfolge der Seite - 17 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaDefinition/Deklaration im Quellcode und dem tatsächlichen Layout existieren jedoch nicht. ZurErinnerung: Der Heap unterliegt anderen Regeln, da dieser Speicher erst zur Laufzeit erstellt wird. buf1 buf0 0x0012FF64 0x0012FF68 1. Vorher A B C 0 1 2 3 4 0 2. strcyp() 3. Nachher 1 2 3 4 0 2 3 4 0Abbildung 3-1: Die Buffer buf0 und buf1 im SpeicherGibt man mittels printf("buf0 %sn", buf0); den String buf0 aus, so wird nichts ausgegeben,weil der String-Terminator bereits an erster Stelle steht und printf() mit dem Formatstring %s, nurZeichen bis zu dem ersten vorkommenden 0 ausgibt.Off-By-One Buffer-Overflows sind in den meisten Fällen nichts weiter als ärgerlicheProgrammierfehler die relativ schwer zu finden sind. Der Nutzen ist für Angreifer beiProgrammierfehlern dieser Art meist sehr beschränkt. Hauptsächlich deshalb, weil derSpeicherbereich der durch den Benutzer beeinflusst werden kann, mit einer Speichereinheit (imobigen Beispiel 1 Byte) nur sehr wenig Spielraum bietet. Die Folgen hängen aber davon ab, welcheArt von Informationen in den überschreibbaren Bereichen gespeichert sind.Wie interessant selbst ein Off-By-One Buffer-Overflow werden kann zeigt der folgende Abschnitt.3.1.2 Mit Buffer Overflows den Kontrollfluss ändernIm dem folgenden Programm kann ein Buffer Overflow dazu verwendet werden eine Variable zuüberschreiben, die wesentlich für den Ablauf des Programms ist. Quellcode: Kapitel-3-1-2_auth_overflowauth_overflow.c#include <stdio.h>#include <stdlib.h>#include <string.h>#include "hacking.h"int check_authentication(char *password) { int auth_flag = 0; char password_buffer[8] = {F, F, F, F, F, F, F, F}; printf("~~~ vorher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~n"); printf("dump: password_buffern"); Seite - 18 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista dump(password_buffer, 8); printf("dump: auth_flagn"); dump(&auth_flag, 4); strcpy(password_buffer, password); if(strcmp(password_buffer, "password") == 0) auth_flag = 1; if(strcmp(password_buffer, "adminpw") == 0) auth_flag = 1; printf("~~~ nachher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~n"); printf("dump: password_buffern"); dump(password_buffer, 8); printf("dump: auth_flagn"); dump(&auth_flag, 4); return auth_flag;}int main(int argc, char *argv[]) { //... gekürtzt if(check_authentication(argv[1])) { printf("n-=-=-=-=-=-=-=-=-=-=-=-=-=-n"); printf(" Zugang freigegeben.n"); printf("-=-=-=-=-=-=-=-=-=-=-=-=-=-n"); } else { printf("nZugang verweigert.n"); } getchar();}Hinweis: die Funktion dump() ist in der Include-Datei hacking.h definiert. Sie gibt von einer, perersten Parameter übergebenen Speicheradresse ausgehend, eine mit dem zweiten Parameterdefinierte, Menge an Speicherinhalten, aus.Das Programm übernimmt den ersten Parameter, den das Hauptprogramm übergeben bekommt undkopiert ihn in der Funktion check_authentication() in einen Buffer, der als Zwischenspeicherdient.Stimmt das Passwort mit einem der gespeicherten Passwörter überein, so wird die Variableauth_flag auf 1 gesetzt, was "wahr" entspricht.Das Hauptprogramm nimmt den Rückgabewert der Funktion check_authentication() umZugang zu einem geschützten Bereich zu gewähren oder zu verweigern. Seite - 19 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaDabei gibt es in dem Programmfluss keinen Else-Zweig, der im Falle, keiner Übereinstimmung, die dieVariable auth_flag auf 0 setzen würde. Der Programmierer hat diesen Fall durch das Initaialisierenmit 0 abgedeckt.Gegen dieses Vorgehen ist prinzipiell nichts einzuwenden. Das Problem mit dem obigen Code istjedoch, dass die Funktion strcpy() unabhängig von der Größe des Zielbuffers password_bufferalle Zeichen bis zum ersten 0 kopiert.Diese Frage lässt sich mit Hilfe der Programmausgabe beantworten:~~~ vorher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dump: password_buffer0012FF54: 46 46 46 46 46 46 46 46 | FFFFFFFFdump: auth_flag0012FF5C: 00 00 00 00 | ....... gekürztWie hier zu sehen ist liegt die Variable auth_flag unmittelbar nach dem Buffer password_bufferim Speicher.Das bedeutet, sollte es dem Benutzer möglich sein, dem Programm als ersten Parameter mehr alsacht Zeichen zu übergeben, so findet durch strcpy()ein Buffer Overflow in den Speicherbereichder Variable auth_flag statt.Startet man das Programm beispielsweise folgendermaßen:auth_overflow.exe 12345678ASo erhält man folgende Ausgabe:~~~ vorher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dump: password_buffer0012FF54: 46 46 46 46 46 46 46 46 | FFFFFFFFdump: auth_flag);0012FF5C: 00 00 00 00 | ....~~~ nachher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dump: password_buffer0012FF54: 31 32 33 34 35 36 37 38 | 12345678dump: auth_flag);0012FF5C: 41 00 00 00 | A...-=-=-=-=-=-=-=-=-=-=-=-=-=- Access Granted.-=-=-=-=-=-=-=-=-=-=-=-=-=-Wie zu sehen ist, hat der Benutzer mittels "12345678" acht Zeichen übergeben und noch einzusätzliches A angehängt.Wie in der Abbildung 3-2 zu sehen ist, wird das A an die Speicheradresse 0x0012FF5C geschrieben.Der Rückgabewert der Funktion check_authentication() ist als int deklariert und wird durchdas Programm als wahr oder falsch interpretiert. Da in der Programmiersprache c alle Werte ungleich0 dem Wert "Wahr" entsprechen, wird im Falle eines Overflows der Zugang zum geschützten Bereichgewährt. Seite - 20 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Overflowrichtung password_buffer auth_flag 0x0012FF54 0x0012FF5C 1. Vorher F F F F F F F F 0 0 0 0 2. strcyp() 3. Nachher 1 2 3 4 5 6 7 8 A 0 0 0Abbildung 3-2: Buffer Overflow von password_buffer in auth_flagDieses Beispiel zeigt eindrucksvoll, wie bereits ein einziges Zeichen an der richtigen Stelle genügenkann, um den Ablauf eines Programms wesentlich zu beeinflussen.Hinweis: Werden in diesem Programm mehr wie zwölf Zeichen übergeben, so stürzt das Programmab, da Informationen auf dem Stack überschrieben werden, die für den weiteren Programmablaufbenötigt werden. Abgesehen von Programmabstürzen, bietet diese Möglichkeit der Manipulationvon Werten, einen interessanten Ansatzpunkt für weitere Angriffsmöglichkeiten, auf die in denfolgenden Abschnitten eingegangen wird.Bei dem zuletzt vorgestellten Overflow, ist außerdem zu bedenken, dass nicht nur Zahlenwerte undStrings auf diese Weise manipuliert werden können. Es ist ebenso möglich Funktionspointer zuüberschreiben. Auf diese Weise kann wahlfrei, vorhandener, oder auch eingeschleusterProgrammcode ausgeführt werden.Damit kommt dieses Grundagekapitel zu den "nützlicheren" Angriffsmöglichkeiten mittels BufferOverflows: Dem Ausführen von beliebigem Code.3.1.3 Ausführen von beliebigem CodeUm auf einem Zielsystem beliebigen Code auszuführen sind prinzipiell immer zwei Schritte nötig 1. Den auszuführenden Code in den Arbeitsspeicher des Zielsystems einschleusen 2. Eine Möglichkeit finden den eingeschleusten Code ausführen zu lassenDer erste Punkt lässt sich, ähnlich wie im Beispiel des letzten Abschnitts, mittels Programmparametererreichen.Der zweite Punkt wird meistens durch das Manipulieren eins Funktionspointers erreicht. Dazukönnen vom Programmierer selbst angelegte Funktionspointer verwendet werden, oder aber auchauf dem Stack liegende Rücksprungadressen. [ 5 ] Seite - 21 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaDa die wirkliche Herausforderung mehr beim Ausführen, als beim Einschleusen liegt, werden in denrestlichen Abschnitten dieses Kapitels einige Möglichkeiten vorgestellt, um den Code zur Ausführungzu bringen.3.1.4 Klassische Stack-basierende AngriffeStack-basierende Angriffe verfahren normaler weise streng nach dem bereits vorgestellten Schema: 1. Den auszuführenden Code in Arbeitsspeicher des Zielsystems einschleusen 2. Eine Möglichkeit finden den gespeicherten Code ausführen zu lassenEine Möglichkeit den Code einzuschleusen haben wir bereits kennen gelernt: Die strcpy()-Funktion.Kommen wir also zu Punkt zwei: Dem Starten des eingeschleusten Codes.Bei klassischen Stack-basierenden Angriffen erfolgt das Starten des Codes durch das Manipulieren,der auf dem Stack gespeicherten Rücksprung-Adresse(RET). Betrachtet man die in Abbildung 3-3dargestellte Speicherbelegung, so stellt man fest, dass RET an einer höheren Adresse im Speicherliegt als die lokalen Variablen. Beispielhaftes Stackframe 0000000h (Kleine Adressen) Gespeicherte Register der aufgerufenen Funktion Overflowrichtung Wachstumsrichtung Lokale Variablen Stack Frame Pointer (SFP) Return Adresse (RET) FFFFFFFFh Parameter (Große Adressen)Abbildung 3-3: Beispielhaftes Stackframe unter Windows allgemeinDa lokal angelegte String-Arrays (Buffer) nichts weiter sind als die in Abbildung 3-3 dargestelltenlokalen Variablen, ist es möglich, mit einer ausreichend großen Eingabe die Return-Adresse zuüberschreiben.Damit der nächste Schritt, das Bestimmen der gewünschten Rücksprungadresse, einfacher ist, wirdals Füllmenge (um RET zu erreichen) ein spezieller Assembler-Befehl verwendet: ein NOP. NOP stehtfür No OPeration und hat als einzige Aufgabe einen Maschinenzyklus zu verbrauchen. Danach führt Seite - 22 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vistadie CPU die Befehlsverarbeitung mit dem darauf folgenden Befehl fort. Typischer Weise werden andieser Stelle einige NOPs aufeinander folgen und bilden so einen NOP-Sled2.Um nun den eingeschleusten Code ausführen zu lassen, muss RET auf den ersten eingeschleustenBefehl zeigen. Wenn ein NOP-Sled verwendet wird, reicht es an dieser Stelle aus, einen beliebigenPunkt auf dem NOP-Sled zu treffen. Das ist besonders hilfreich, weil der Compiler mit dem dasverwundbare Programm übersetzt wird möglicher Weise einige Optimierungen durchführt, die dieexakte Positionsbestimmung des ersten Befehls erschweren können. Aus demselben Grund ist esüblich die gewünschte Return-Adresse mehrfach zu wiederholen.Besondere Aufmerksamkeit muss man der Ausrichtung der eingeschleusten Return-Adresse widmen.Das bedeutet man muss darauf achten, dass das erste Byte der selbst geschriebenen Return-Adresseauch wirklich über das erste Byte der alten Return-Adresse geschrieben wird. Ohne Verwendungeines Debuggers, lässt sich die korrekte Ausrichtung am einfachsten durch Probieren finden. Dabeisollten maximal vier Versuche nötig sein, da eine Adresse bei 32-Bit-Systemen nur 4 Byte groß ist undes somit nur vier Möglichkeiten gibt.Die absolute Adresse des Puffers wird meist mittels eines Debuggers ermittelt und auf x86-Systemenin Little-Endian-Anordnung eingebgeben. Interessant hierbei ist auch, dass der Stack eines Prozessesimmer an derselben Adresse beginnt, was bedeutet, dass auch hier Probieren zum Ziel führen kann.Alternativ können zur Positionsbestimmung von Buffern auch Formatstring-Verwundbarkeitverwendet werden [ 5 ] . Auf Formatstrings wird in dieser Arbeit jedoch nicht eingegangen, weil sienicht Teil des Themas "Buffer-Overflows" sind.Insgesamt wird dem auszunutzenden Programm die in Abbildung 3-4 dargestellte Kombinationübergeben. Diese Kombination aus NOP-Sled, Payload3 und widerholter Return-Adresse, wird häufigals Angriffsvektor bezeichnet. RET NOP-sled Payload (mehrfach wiederholt)Abbildung 3-4: AngriffsvektorBleibt noch zu erwähnen, dass die Speichermenge die für den Payload zur Verfügung steht, durch diePosition der Return-Adresse begrenzt ist. Dieses Problem lässt sich aber durch einen relativenSprung, nach den Speicherbereich mit der Return-Adresse umgehen. [ 10 ]2 NOP-Sled/NOP-Sledge: Übersetzt: NOP-Schlitten. Das bedeutet, eine Folge von NOPs führen direkt, ohne jede weitereFunktion, zu dem nächsten „richtigen“ Maschinenbefehl. Beispielsweise dem ersten Befehl des Sehellcodes.3 Der Payload/Shellcode besteht aus Maschinencode. Er ist der Teil des einzuschleusenden Codes, der die eigentlicheFunktionalität beinhaltet. Häufig werden die Begriffe Payload und Shellcode als Synonym verwendet. Details zu Shellcodewerden in dem Kapitel 3.2 behandelt Seite - 23 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Tools-Hinweis Die felxibelste Möglichkeit einen Angriffsvektor zu erstellen ist mit der Programmiersprach Perl. Perl gibt es auch für Windows: Toolsverzeichnis IVBeispiel: stack-overflow.c im Quellcode-Ordner "Kapitel-3-1-4_stack-overflow"Eine Variante des Programms auth_overflow.c ist unter dem Namen stack-overflow.c Quellcode-Archiv zu finden. Dieses Programm bekommt seine Eingabe dabei nicht als Parameter, sondern liestvon einer Datei. Außerdem wird nicht die Funktion strcpy() verwendet, sondern die Funktionmemcpy(). Für diese Modifikationen gibt es zwei Gründe: 1. Mit der Windows-Eingabeaufforderung ist es nicht ohne weiteres möglich einem Programm, per Parameter Zeichen zu übergeben, die nicht "druckbar" sind. Da das auf die meisten Maschinenbefehle zutrifft, ist ein einfaches Einschleusen von Code über die Kommandozeile nicht möglich. Abhilfe würde an dieser Stelle das Programm cat4 schaffen mit dem man die Eingabe an das Programm umleiten kann. Cat ist aber nicht Bestandteil von Windows. Zudem besteht das Problem der Parameterübergabe mit nichtdruckbaren Zeichen auch in den meisten Debuggern. Aus diesem Grund liest das Demo-Programm aus einer Datei. 2. Wie in dem Abschnitt 2.1 beschrieben, liegt der für das Programm selbst zur Verfügung stehende Speicher im niederen Adressbereich. Deshalb ist die Wahrscheinlichkeit sehr hoch, dass der Buffer in dem der eingeschleuste Code liegt in einem Adressbereich liegt, der mit zwei führenden Nullen (0x00AABBCC) beginnt. Das bedeutet, dass strcpy() die Speicheradresse nicht mehr kopiert. Es gibt eine Reihe von Möglichkeiten den eingeschleusten Code trotz dieses strcpy()-Problems zur Ausführung zu bringen (beispielsweise "return to libc"). Um das Beispiel einfach zu halten wird dieses Problem an dieser Stelle durch die Verwendung von memcpy() umgangen.Trotz dieser zwei Vereinfachungen, bleibt das demonstrierte Prinzip in allen Fällen gleich: DenAngriffsvektor einschleusen und den Maschinencode zur Ausführung bringen.Ein funktionierender Angriffsvektor zu dem Programm stack-overflow.c ist ebenfalls im Quellcode-Archiv zu finden. Dabei wird der Angriffsvektor mittels eines Perl-Skripts generiert. Der hierbeiverwendete Payload startet hierbei nichts weiter als den Windows-Taschenrechner clac.exe. Detailszur Erstellung von Payload folgt in dem Abschnitt 3.2.4 cat ist ein Kommandozeilen-Tool aus der UNIX-Welt, mit dem sich unter anderem sehr einfach Eingaben aus einer Dateilesen lassen. Das Tool gibt es auch für Windows Seite - 24 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaGekürzte Ausgabe des Programms stack-overflow.exe~~~ nachher ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dump(password_buffer...);0012FA48: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 | ................0012FA58: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 | ................ NOP-sled0012FA68: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 | ................0012FA78: 29 c9 83 e9 dd d9 ee d9 74 24 f4 5b 81 73 13 b3 | ).......t$.[.s..0012FA88: 87 5d 85 83 eb fc e2 f4 4f 6f 19 85 b3 87 d6 c0 | .]......Oo......0012FA98: 8f 0c 21 80 cb 86 b2 0e fc 9f d6 da 93 86 b6 cc | ..!.............0012FAA8: 38 b3 d6 84 5d b6 9d 1c 1f 03 9d f1 b4 46 97 88 | 8...]........F..0012FAB8: b2 45 b6 71 88 d3 79 81 c6 62 d6 da 97 86 b6 e3 | .E.q..y..b......0012FAC8: 38 8b 16 0e ec 9b 5c 6e 38 9b d6 84 58 0e 01 a1 | 8.....n8...X... Payload0012FAD8: b7 44 6c 45 d7 0c 1d b5 36 47 25 89 38 c7 51 0e | .DlE....6G%.8.Q.0012FAE8: c3 9b f0 0e db 8f b6 8c 38 07 ed 85 b3 87 d6 ed | ........8.......0012FAF8: 8f d8 6c 73 d3 d1 d4 7d 30 47 26 d5 db f9 85 67 | ..ls...}0G&....g0012FB08: c0 ef c5 7b 39 89 0a 7a 54 e4 3c e9 d0 a9 38 fd | ...{9..zT.<...8.0012FB18: d6 87 5d 85 50 fa 12 00 50 fa 12 00 50 fa 12 00 | ..].P...P...P...0012FB28: 50 fa 12 00 50 fa 12 00 50 fa 12 00 50 fa 12 00 | P...P...P...P... RET0012FB38: 50 fa 12 00 50 fa 12 00 50 fa 12 00 50 fa 12 00 | P...P...P...P... (mehrfach wiederholt)0012FB48: 50 fa 12 00 50 fa 12 00 50 fa 12 00 50 fa 12 00 | P...P...P...P...0012FB58: ff | .dump(&auth_flag, 4);0012FA44: 00 00 00 00 | ....Erklärung:1. Der Wert 90 Hex entspricht einem NOP2. Der rot markierte Bereich ist der Maschinencode zum Starten von calc.exe3. Am Schluss folgt die mehrfach wiederholte Return-Adresse3.1.5 Exception Handler-basierende AngriffeDie Programmiersprache c bietet von sich aus keinerlei Möglichkeiten, Ausnahmen imProgrammablauf abzufangen. Eine solche Ausnahme ist beispielsweise eine Division durch Null. MitC++ wurde dieser Missstand behoben und es ist somit, durch Elemente der Programmiersprache,möglich eine Ausnahmebehandlung durchzuführen. Das bedeutet, dass ein Programm, das eineDivision durch null durchführt, nicht mehr zwangsläufig abstürzt, sondern durch eine geeigneteAusnahmebehandlung weiterlaufen kann. [ 11 ]Microsoft hat für die Programmiersprache c eigene Elemente eingebracht, mit denen eineAusnahmebehandlung möglich wird: __try und __exceptDiese Art der Ausnahmebehandlung nennt sich Structured Exception Handling (SEH). Im Unterschiedzu c++ wird die Art der Ausnahme mittels eines unsigned int ermittelt, während in c++ anhand desKlassen-Typs unterschieden wird. [ 11 ] [ 12 ] Seite - 25 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaBeispiel: Strukturierte Ausnahmebehandlung (SEH) - Division durch Null Quellcode: Kapitel-3-1-5_exceptionexception.c#include <stdio.h>int MyExceptionHandler(void);int main(int argc,char *argv[]){ int a = 1000, b = 0, c = 0; if(argc != 2){ printf("Divisor als Parameter uebergebenn"); exit(0); } b = atoi(argv[1]); /* Falls eine 0 als erster Programmparameter übergeben wird, wird * eine EXCEPTION_INT_DIVIDE_BY_ZERO ausgelößt */ __try { c = a / b; printf("Ergebnis der Division %i / %i = %in", a, b, c); } __except ( MyExceptionHandler() ){} printf("Programm beendet sichn"); return 0;}/* return 1, damit die Exception nicht and das * Betriebsystem weitergereicht wird */int MyExceptionHandler(void){ printf("Exception.. Ausnahme abgefangen und als behandelt markiert"); return 1;}SEH lässt sich im Zusammenhang mit Buffer Overflows nutzen, um eingeschleusten Code zurAusführung zu bringen. Dabei macht sich der Angreifer den Umstand zu nutze, dass dieFunktionsadresse der Funktion zur Ausnahmebehandlung, wie in Abbildung 3-5 zu sehen ist, auf demStack gespeichert wird. Seite - 26 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Beispielhaftes Stackframe 0000000h (Kleine Adressen) Gespeicherte Register der aufgerufenen Funktion Overflowrichtung Wachstumsrichtung Lokale Variablen Stack Frame Pointer (SFP) Return Adresse (RET) FFFFFFFFh (Große Adressen) Parameter ... Pointer zur nächsten SEH-Funktion Pointer zur SEH-FunktionAbbildung 3-5: Beispielhaftes Stackframe unter Verwendung von SEH [ 13 ]Wie bei den klassischen Stack-basierenden Buffer Overflows, wird von einem verwundbaren Bufferausgehend, diese Funktionsadresse im Speicher überschrieben. Der Unterschied besteht lediglichdarin, dass die Behandlung der Ausnahme veranlasst werden muss, z. B. mit einer Division durchNull. [ 14 ]Interessant ist hierbei, dass jedes Programm mindestens einen, automatisch erstellten SEH besitzt,den der main()-Routine.Im Quellcode-Archiv findet sich im Ordner "Kapitel-3-1-5_exception_exploit" ein vollständigesBeispiel, wie sich SEH unter Windows praktisch ausnutzen lässt.3.1.6 Heap-basierende AngriffeHeap-basierende Angriffe funktionieren prinzipiell genauso, wie alle anderen Buffer-Overflows auch.Es werden Daten überschrieben, die nach einem verwundbaren Puffer im Speicher liegen. Dereinzige Unterschied besteht darin, dass, verglichen mit den anderen Datensegmenten, im Heapandere Daten gespeichert sind.Folgende Daten finden sich vermehrt bzw. nur auf dem Heap: 1. Nutzdaten. Beispielsweise die Variable auth_flag aus dem Abschnitt 3.1.2 (gibt es auch auf beim Stack) Seite - 27 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista 2. Daten die den Programmablauf steuern und vom Programmierer bewusst angelegt wurden (auch auf dem Stack vorhanden, aber selten) 3. Daten die den Programmablauf steuern und vom Compiler automatisch angelegt werden 4. Daten die der Speicherverwaltung dienen. Beispielsweise das Windows-Heap-ManagementDen Punkt "Nutzdaten", wurde bereits in dem Abschnitt 3.1.2 ausführlich behandelt und da an dieserStelle keine wesentlichen Unterschiede existieren, wird an dieser Stelle nicht näher daraufeingegangen.Der zweite Punkt ist vom prinzipiellen Vorgehen bereits bekannt.Der Punkt Nummer Drei bietet interessante Möglichkeiten, ist in der Praxis jedoch kaum anzutreffen.Punkt Nummer Vier hat in den letzten Jahren deutlich an Bedeutung gewonnen und ist vor allem imZusammenhang mit dem Windows-Heap-Management interessant. Deshalb wird im Folgenden dasprinzipielle Vorgehen bei Angriffen auf das Windows-Heap-Management erläutert.Angriffe auf das Windows-Heap-ManagementWie bereits in dem Abschnitt 2.1.3 beschrieben, ist ein Heap, der mit HeapCreate()erzeugt wird,durch eine Reihe von Listen organisiert. Wird mit der Funktion HeapAlloc() ein Speicherbereichangefordert, so wird von der Heapverwaltung ein passendes Stück Speicher gesucht. Dieses StückSpeicher wird, unmittelbar vor dem nutzbaren Bereich, mit einem Header versehen, derInformationen für die Heapverwaltung enthält. [ 15 ] [ 8 ]Bei Angriffen auf die Heapverwaltung ist es das Ziel, die Headerinformationen derart zumanipulieren, dass eine begrenzte Menge an Daten an eine beliebige Stelle im Speicher geschriebenwerden kann. Hierbei macht sich der Angreifer zunutze, dass die Headerinformationen Pointerenthalten, die zur Verkettung der Listen und zur Referenzierung des Nutzspeichers dienen. BeimAnfordern und Freigeben von Speicher werden die Header teilweise kopiert und unter bestimmtenBedingungen in einer doppelt verketteten Liste gespeichert. Zur Bestimmung der jeweiligenNachbarelemente werden die Headerinformationen verwendet. Somit ist es möglich, durch gezieltesÜberschreiben der entsprechenden Pointer, einen wahlfreien Schreibzugriff mit einer Datenmengevon 4 Bytes zu erreichen. Dieser Vorgang lässt sich prinzipiell beliebig oft wiederholen, meist istjedoch eine Menge von 4 Bytes vollkommen ausreichend, da dies die Größe eines Pointers ist. Somitlässt sich beispielsweise im Process Execution Block (PEB) ein Pointer überschreiben. Hier bietet sichder Pointer auf die Funktion ExitProcess() an, die vor dem endgültigen Beenden des Prozessesausgeführt wird. Durch das Überschreiben des ExitProcess()-Pointers kann eingeschleuster Codedurch das Beenden des Programms zur Ausführung gebracht werden. [ 15 ] [ 8 ] [ 16 ] [ 17 ] [ 18 ] [16 ] [ 19 ]In der Praxis gibt es eine Vielzahl von Variationen der eben beschriebenen Methode. Hierbei habenjedoch alle Varianten die Gemeinsamkeit, dass sie durch gezieltes Manipulieren der Header, Code zurAusführung bringen. Seite - 28 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaEinen besonderen Reiz haben vor allem die Varianten, die es dem angegriffenen Programmermöglichen weiter zu laufen, indem sie die beschädigten Heapstrukturen wieder mit gültigenWerten reparieren. Ein weiterer Grund für die gestiegene Popularität von Angriffen auf dasHeapmanagement sind vor allem Mechanismen, die zum Schutz des Stacks eingeführt wurden undden Heap so zum schwächsten Glied der Kette werden ließen. Details zu aktuellenSchutzmechanismen des Stacks werden im Kapitel 4.6 behandelt.3.2 Shellcode und PayloadDie beiden Begriffe Shellcode und Payload werden heutzutage häufig als Synonym verwendet. Strenggenommen ist der Shellcode jedoch eine spezielle Form des Payloads: 1. Der Payload an sich ist der Teil des Angriffsvektors, der die eigentliche Funktionalität beinhaltet, also beispielsweise das Starten des Windows-Taschenrechners. 2. Der Shellcode ist streng genommen ein spezieller Payload, der eine Shell (Eingabeaufforderung) startet, mit der der Angreifer interagieren kann.In dieser Arbeit wird häufig ebenfalls der Begriff "Shellcode", anstelle des historisch korrektenBegriffes verwendet. Die Begründung ist die Tatsache, dass der Begriff Shellcode einen höherenWiedererkennungswert bietet und selbst in Printmedien gebräuchlicher ist.Da das Thema Shellcode, bei sorgfältiger Behandlung, den Umfang dieser Arbeit bei weitemsprengen würde, wird im Folgenden nur stichpunktartig auf Anforderungen an Shellcodeeingegangen.3.2.1 Anforderungen an ShellcodeAnforderungen an die Darstellung des Shellcodes : 1. Zeichensatz: Shellcode unterliegt einigen Einschränkungen bezüglich der verwendbaren Zeichen. Beispielsweise darf in Shellcode der durch strcpy() eingeschleust wird, nicht das Zeichen 0x00 vorkommen, weil strcpy() nur bis zu diesem Zeichen kopiert. Außerdem werden die eingegebenen Zeichen häufig von dem angegriffenen Programm geprüft und z. B. nur druckbare Zeichen verarbeitet. 2. Kompatibilität: Die Kompatibilität von Shellcode ist unumgänglich auf eine Art der Speicheranordnung beschränkt: entweder Big- oder Little-Endian. 3. Kodierung: Soll eine Funktion angegriffen werden die eine UTF-8 kodierte Zeichenfolge erwartet, so muss außer der Big- und Little-Endian-Anordnung außerdem eine bestimmte Reihenfolge von Zwei-Byte-Paaren eingehalten werden. [ 20 ] 4. Kompaktheit: Häufig ist die Menge an einschleusbaren Zeichen beschränkt. 5. Unentdeckt bleiben: Unter Umständen passiert der Shellcode auf dem Weg zum Ziel Intrusion Detection Systeme (IDS), die die übertragenen Daten auf bekannte Schad- Signaturen hin überprüfen. Seite - 29 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaAnforderungen an die Logik des Shellcodes: 1. Betriebssystemabhängig: Da die meisten Betriebssysteme einen grundliegend unterschiedlichen Zugriff auf Systemfunktionen haben, muss der Shellcode meistens Betriebssystemspezifisch sein. 2. Behandlung der Anwendung: Unter bestimmten Umständen hat man die Möglichkeit, das angegriffene Programm weiter laufen zu lassen und so die Wahrscheinlichkeit, das der Angriff entdeckt wird stark zu reduzieren.3.2.2 Besonderheiten von Windows-ShellcodeVerglichen mit Shellcode der unter Linux lauffähig ist, gibt es für Windows-Shellcode eine Reihe vonBesonderheiten1. Windows-Shellcode ist größer als Linux-Shellcode [ 21 ]2. Keine 1-zu-1-Abbildung der Bibliotheksfunktionen des Betriebssystems zu den Systemcalls auf Kernelebene [ 21 ]3. Die verwundbaren Buffer liegen meist in einem Speicherbereich, der mit 0x00… beginnt und somit ein nicht verwendbares Zeichen darstellt.3.2.3 Was möglich istJe nachdem welchen Anforderungen (siehe 3.2.1) der eingeschleuste Code unterliegt, ergeben sichunterschiedliche Möglichkeiten:1. Erweitern der Rechte durch angreifen von lokalen Prozessen die mit umfangreicheren Privilegien ausgestattet sind.2. Nachladen von Systemfunktionen, falls der Prozess eine für den Angriff wichtige Dll-Funktion5 nicht geladen hat, kann man diese Dll selbst nachladen.3. Nachladen von Code, falls der eingeschleuste Code in seiner Größe beschränkt war, hat man die Möglichkeit z. B. aus dem Internet Code nachzuladen. [ 21 ]Wenn man davon ausgeht, dass man die Möglichkeit hat, eine unbegrenzte Menge aneingeschleusten Code, mit Administrator-Rechten auszuführen, dann hat man praktisch keineEinschränkungen mehr. Man kann beispielsweise:1. Ein lokales Benutzer-Konto erstellen (Local Access)2. Einen Prozess starten, der beliebige Befehle über das Netzwerk ausführt (Remote Access)3. Einen Keylogger installieren, der sämtliche Aktivitäten des Benutzers aufzeichnet, inklusive Tastatur- und Mausinteraktion (Spionage)5 Dynamic Link Library (Dll) Seite - 30 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista3.2.4 Abstraktes Beispiel: Portbind Shellcode für WindowsAn dieser Stelle folgt ein eine allgemeine Beschreibung, der Vorgehensweise, zum Starten einerRemote-Shell: [ 21 ] 1. Suchen der Datei kernel32.dll 2. Auflösen der Symbole GetProcAddressA(), LoadLibraryA() sowie ExitProcess() 3. Laden der Winsock Bibliothek ws2_32.dll 4. eine Shell an einen TCP-Port binden 4.1. Socket erzeugen 4.2. Socket an Port binden 4.3. Auf dem Port auf eingehende Verbindung warten 4.4. Verbindung akzeptieren 5. Kommandointerpreter starten 6. Den Elternprozess sauber beenden oder die beschädigten Strukturen reparierenUm nicht zu sehr vom eigentlichen Thema, den Buffer Overflows, abzukommen, wird an dieser Stellenicht weiter auf das Themengebiet Shellcode eingegangen. Interessierten sei [ 21 ] für weitereInformationen empfohlen.Es folgt nun eine Vorstellung der Verschiedenen Mechanismen in Windows, die dazu dienen denSchaden durch Buffer-Overflows so gering wie möglich zu halten. Seite - 31 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista4 Das Sicherheits-Ensemble von Windows und seine SchwachstellenDieses Kapitels hat es zum Ziel, die Frage nach dem betitelten Stack- und Heap-Overflow-Schutz beiWindows XP und Windows Vista zu klären. Nicht eingegangen wird auf weitere nützliche Funktionenzur Erhöhung der Sicherheit, die nichts direkt mit Buffer-Overflows zu tun haben.Die vorhergegangenen beiden Grundlagenkapitel, haben sich im Wesentlichen damit beschäftigt,welche Bedingungen, unter früheren Windowsversionen, gegeben sein mussten, um einem Buffer-Overflow erfolgreich auszunutzen.Dieses Kapitel beschäftigt sich zu Beginn damit, wie sich der Schaden, eines unter fremder Kontrollestehenden Programms, einschränken lässt und welche neuen Ansätze mit Windows Vista verfolgtwerden (bis einschließlich Kapitel 4.2).Anschließend werden Methoden von Windows XP und Vista analysiert und bewertet, die es zum Zielhaben, Angriffe mittels Buffer-Overflows so früh wie möglich zu entschärfen.4.1 Das Windows-Zwei-Schichten-ModellDen grundlegendsten Schutzmechanismus der Windows-Architektur bildet das Zwei-Schichtenmodell.Unter Windows ist die gesamte Funktionalität in zwei unterschiedlich privilegierte Bereicheeingeteilt: [ 4 ]  Kernel-Mode (Ring 0): Der Modus mit den höchstmöglichen Privilegien – Keine Einschränkungen beim Zugriff auf die Ressourcen des Kernels  User-Mode (Ring 1): Eingeschränkter Modus – Beim Zugriff auf Systemressourcen muss eine ganze Abfolge von Funktionen abgearbeitet werden, die vom Ring0 als Services zur Verfügung gestellt werden.Häufig werden User- und Kernel-Mode wie in Abbildung 4-1 grafisch dargestellt. Dabei sollsymbolisiert werden, dass auf die innen liegenden Funktionen und Ressourcen nur über dieverbindende Schicht zugegriffen werden kann. Seite - 32 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Ring1 (User-Mode) Ring0 (Kernel-Mode) KernelAbbildung 4-1: Windows-Zwei-Schichten-Modell [ 4 ]Im Ring0 finden sich vorrangig Gerätetreiber und Systemfunktionen. Im Ring1 hingegen findet sichalles Übrige, z. B. ein Browser oder ein FTP-Server.Schafft es ein Angreifer direkt im Ring0 einen Programmierfehler für sich zu nutzen, so stehen impraktisch keine Hindernisse mehr im Weg. Allerdings erfordern Angriffe auf dieser Ebene sehrspezifisches Detailwissen, das äußerst selten offen zugänglich ist. Dies ist auch der Grund dafür, dassAngriffe auf den Ring0 verhältnismäßig selten vorkommen. Ein Beispiel für einen erfolgreichenAngriff auf den Gerätetreiber diverser W-LAN-Chips ist der Angriff von Jon Ellch (Pseudonym: JonnyCache)[ 22 ] . [ 4 ] [ 23 ]Meist ist es aus dem oben genannten Grund einfacher, eine verwundbare Anwendung im Ring1anzugreifen. Jedoch haben Prozesse im Ring1 einen Prozess-Kontext, der einenrechtebeschreibenden Token beinhaltet. Näheres dazu im nächsten Abschnitt.4.2 Zugriffsrechte, Authentifizierung und Access TokenMeldet sich ein Benutzer an einem Windows-System an, so bekommt er vom Local Security AuthoritySubsystem Service (LSA) ein Access Token zugeteilt. Dieser Token besteht aus einem SecurityIdentifier (SID), der zu seinem Benutzerkonto gehört, und einigen weiteren SIDs, die zu seinenGruppen gehören in denen er Mitglied ist. Eine solche SID ist eine 48 Bit lange Nummer, diedomainweit einzigartig ist. Außerdem enthält der Token, falls definiert, eine Liste von nicht erlaubtenSIDs und eine Liste mit Privilegien, die zu den jeweiligen SIDs gehören. Privilegien sind z. B. das Rechteinen Treiber zu laden (SeLoadDriverPrivilege) oder das Recht den Computer herunterzufahren(SeShutdownPrivilege).[ 4 ] [ 24 ] Seite - 33 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaAlle Ressourcen, auf die ein Benutzer theoretisch zugreifen kann, haben eine so genannteDiscretionary Access Control List (DACL)6. Praktisch wird der Zugang auf die Ressource durch LSAreglementiert. Das bedeutet, der Zugriff ist nur erlaubt, wenn eine der SIDs aus dem Token desBenutzers in der DACL-Liste unter dem entsprechenden Privileg (Lesen, Schreiben usw.) zu finden ist.[4]Nach [ 4 ] lässt sich zur besseren Übersicht eine Einteilung in Subjekte und Objekte vornehmen 1. Subjekte: Einheiten, die Aktionen durchführt – unter Windows sind das Prozesse 2. Objekte: Sind die Empfänger einer Aktion – unter Windows zugriffsgeschützte Objekte mit zugehörigen DACL wie z. B. Dateien und Registry-Einträge4.2.1 Rechte von Prozessen unter WindowsStartet ein am System angemeldeter Benutzer einen Prozess, so wird in dem Prozess-Kontext derToken des Benutzers gespeichert. Fortan darf der Prozess (Subjekt) auf alle Ressourcen (Objekte)zugreifen, auf die auch der Benutzer durch seinen Token Zugriff hat.Ist nun unter Windows XP ein Administrator am System angemeldet und startet den InternetExplorer, so hat der Browser denselben Token wie der Administrator. Surft der Administrator nunbeispielsweise über eine Seite, die den populären Animated-Cursor Exploit7 eingebaut hat, so stehendem Angreifer keinerlei Hindernisse im Weg. Er hat dank des hoch-privilegierten Token, mit der SIDdes angemeldeten Administrators, vollständigen Zugriff auf das gesamte System.Mit Windows 2000 wurde die Möglichkeit eingeführt, einen Kindprozess/Thread mit einemeingeschränkten Token zu starten. Der eingeschränkte Token kann, ausgehend von dem Original-Token, wie folgt definiert werden: Privilegien entfernen, SIDs entfernen, nicht erlaubte SIDshinzufügen. Wurde ein Thread mit einem eingeschränkten Token gestartet, so ist er an die neuenEinschränkungen gebunden. Allerdings ist es möglich dem Thread mit dem eingeschränkten Token,wieder den uneingeschränkten Token zuzuweisen. Weil diese Möglichkeit besteht, empfiehlt es sichdie API-Funktion CreateProcessAsUser( ) zu verwenden, so dass diese Möglichkeit nicht mehrbesteht. [ 24 ]Mit Windows Server 2003 wurde es möglich die Privilegien eines Prozess-Token dauerhafteinzuschränken. Diese Möglichkeit ist aber ungleich der des eingeschränkten Token, da hier derProzess dauerhaft seine eigenen Privilegien beschneidet. Alle von ihm erzeugten Kindprozesse erben,nach demselben Prinzip wie bei Windows 2000, den Token des Elternprozesses, z. B. einen, in denPrivilegien eingeschränkten. Die Möglichkeit die SIDs des Token zu modifizieren besteht hier nicht.[24 ]6 DACL wird in der Literatur häufig auch ohne das führende D, nur als Access Control List (ACL), verwendet.Außerdem wird häufig der Ausdruck Security Descriptor als Synonym verwendet.7 Animated-Cursor Exploit: http://www.securityfocus.com/advisories/7814 Seite - 34 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista4.2.2 Windows Service HardeningDa auch Windows-Services nichts weiter wie Prozesse sind, haben auch sie einen Token über den sieim Betrieb ihre Berechtigungen erhalten. Für einen Angreifer sind damit die Standard-Services einerWindows-Installation besonders interessant, weil sie aufgrund ihrer Funktionalität ständig laufen undtypischer Weise Systemfunktionen ausführen, die hohe Privilegien benötigen.Mit Windows Server 2003 wurden zwei neue Service-Konten eingerichtet die den bisherübermächtigen LocalSystem entlasten sollten: LocalService und NetworkService. Dabei sind diebeiden neuen Konten in den Rechten derart beschnitten, dass viele Services nicht mit ihnen arbeitenkönnen und deshalb den bisherigen LocalSystem weiterhin verwenden.[ 4 ]Zur verbesserten Schadensbegrenzung wurde bei Windows Vista eine Reihe von Maßnahmeneingeführt, die ein erheblich granulareres Rechtemanagement wie bisher ermöglichen: 1. Service-spezifische SIDs: Jeder Service hat eine eigene SID. Sinnvoller Weise bekommen nur diejenigen Objekte in ihrer DACL die SIDs des speziellen Services eingetragen, die sie auch wirklich benötigen.[ 4 ] 2. Eingeschränkte SIDs: Die RESTRICTED-SID kennzeichnet einen Prozess, der ein eingeschränktes Token enthält. [ 25 ] (nicht auf Services beschränkt) 3. Reduzierte Privilegien für Services: Überflüssige Privilegien, wie das Debugging Privileg wurden den Diensten generell entzogen [ 4 ] 4. Session 0 Isolation: Unter Windows Server 2003 und früheren Versionen, war es unter Umständen möglich seine Privilegien durch Angriffe auf Services mit höheren Privilegien innerhalb derselben Session zu erweitern. Diese Problem wird dadurch entschärft, dass nur noch Services in der Session 0 laufen und alle vom User gestarteten Anwendungen in eigenen Session (1 und höher) gestartet werden. [ 26 ] [ 27 ] 5. UAC: siehe nächster Abschnitt (nicht auf Services beschränkt)4.2.3 Rechte von Prozessen unter Windows Vista: UACEs ist zwar bekannt, dass es sich nicht empfiehlt mit Administratorrechten im Internet zu surfen, dieKonsequenz als normaler Benutzer an einem System zu arbeiten, haben jedoch nur wenigeAnwender gezogen. Der Hauptgrund hierfür ist die mangelnde Unterstützung seitens Windows. So istes bis zu der Version "Vista" nötig gewesen, eine Druckerinstallation oder das Stellen der Uhrzeit mitAdministratorrechten zu erledigen.UAC steht für User Account Control und soll das Arbeiten als eingeschränkter Benutzer erleichtern.Dazu fragt Windows Vista den Benutzer, falls nötig, automatisch nach dem Passwort, für dasBenutzerkonto, dass zum ausführen der Aktion nötig ist. Dabei ist die Interaktion mit den BS solangegesperrt, bis der Benutzer auf die Anfrage reagiert hat. Seite - 35 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaIm Detail verwendet UAC eine neue Technik namens Mandatory Integrity Control (MIC). MIC ist eineErweiterung für die DACLs um sogenannte Integrity Level (IL). Gespeichert werden diese neuenRechte in den Mandatory ACLs (MACL).Als IL wurden folgende vier Möglichkeiten eingeführt:  Low  Medium (als Standard)  High  SystemJeder Prozess hat in seinem Token zusätzlich ein IL gespeichert. Will ein Prozess mit einem niedrigenIL auf eine Ressource mit einem höheren IL zugreifen, so ist die oben beschriebene Interaktion mitdem Benutzer vonnöten.Damit UAC funktioniert wurde der LSA modifiziert, so dass es jetzt zwei Arten von Token gibt:  einen gefilterten: ohne erweiterte Rechte  einen gelinkten: mit allen OriginalrechtenAußerdem muss der Programmierer im Manifest seiner Anwendung das benötigte IL angeben.Standardmäßig werden alle Prozesse mit dem gefilterten Token ausgeführt. Der gelinkte Token wirdnur verwendet, wenn eine Applikation, aufgrund des Eintrags im Manifest, nach erweiterten Rechtenfragt. Dieses Verhalten führt auch dazu, dass selbst ein angemeldeter Administrator zuerst vomSystem um Erlaubnis gefragt wird, wenn die Aufgabe ein höheres IL erfordert.Als Beispiel für eine sinnvolle Anwendung des UAC kann der Internet Explorer betrachtet werden: Der Internet Explorer läuft per Voreinstellung mit Low-IL, was bedeutet, er kann nur auf Objekte mit LOW-IL SIDs zugreifen. Standardmäßig sind das nur %USERPROFILE%AppDataLocalLow und der Registry-Key HKCUSoftwareAppDataLow. Auf alle anderen Systemressourcen hat der Prozess des IE keinen Zugriff, was die Sicherheit stark erhöht.Wird der IE mit aktivierten UAC betrieben, so wird diese Konstellation häufig als Protected Mode IE(PMIE) oder auch Low Rights Internet Explorer (LoRIE) bezeichnet.UAC ist die für den Benutzer offensichtlichste und auch eine der nützlichsten Sicherheitsmaßnahmenzur Schadensbegrenzung. Allerdings empfinden viele Benutzer die ständige Nachfrage nacherweiterten Rechten als störend. Außerdem funktionieren nicht alle Programme einwandfrei mitUAC. Diese zwei Kritikpunkte führen dazu, dass viele Benutzer UAC Systemweit deaktivieren, was dengesamten Nutzen hinfällig macht. Seite - 36 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista4.3 PatchGuardPatchGuard wurde von Microsoft entwickelt und hat es zum Ziel Software von Drittherstellern daranzu hindern Änderungen am Kernel vorzunehmen. Dadurch soll potentiell gefährlicher Softwareerschwert werden sich einzunisten.Eingeführt wurde PatchGuard mit den Windows-Versionen Server 2003 mit SP1 (64-Bit) und XPProfessional x64. Eine Portierung auf die x86-Versionen ist derzeit nicht geplant. [ 28 ]Da PatchGuard eine Reihe von Unzulänglichkeiten besitzt, die das Umgehen des Schutzes relativeinfach machen, ist der tatsächliche Nutzen in Bezug auf Schadsoftware fraglich. Häufig wird sogarbehauptet, PatchGuard sei lediglich ein Instrument von Microsoft, um die Dritthersteller dazu zuzwingen, saubereren und stabileren Code zu schreiben. [ 29 ]Viel Kritik an dem System gab es auch von den Herstellern von Sicherheits-Software, wie Anti-Viren-Software und Rootkit-Detection-Tools, da sich diese Produkte häufig an den, durch dieses Systemnicht mehr erreichbaren Stellen, eingenistet haben, um so von einem möglichst uneingeschränktenPunkt aus operieren zu können. [ 29 ]Eine umfassende Analyse der neusten Version (v3) von PatchGuard ist im Internet unter [ 28 ] zufinden.4.4 Process Exection Block (PEB) RandomizationÜberblickMit Windows XP SP28 wurde eine Funktionalität namens PEB-Randomization eingeführt. Ihr Ziel istes, Angriffe zu erschweren, die zur Codeausführung PEB-Einträge manipulieren. Im Process ExectionBlock (PEB) sind vor allem für Angriffe interessante Funktions-Pointer gespeichert, wie ein Pointer aufdie Funktion ExitProcess().FunktionsweiseBeim Programmstart wird die Basisadresse des PEB dynamisch gewählt. Dadurch ist ein Remote-Exploit9, dass den PEB als Einstiegspunkt verwendet, nicht mehr zuverlässig, da die zuüberschreibende Adresse des Funktions-Pointers in dem, jetzt an einem zufälligen Ort im Speicherliegenden, PEB gespeichert ist.8 Funktionalität ist auch in Server 2003 SP1 / Vista vorhanden9 Ein Remote-Exploit ist dadurch charakterisiert, dass der Angreifer entfernt über ein Netzwerk zugreift undnicht an der Maschine selbst sitzt. Seite - 37 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaSchwachstellenWie sich ein einer Untersuchung von Symantec herausstellte [ 30 ] , beschränkt sich die Anzahl derMöglichkeiten, für die Basisadresse des PEB, auf 16. Hinzu kommt noch, dass die Adresse in 20% allerFälle gleich ist.Effektiver SchutzDie Möglichkeit verlässliche Remote-Exploits zu schreiben wurde reduziert. Die Option der Brute-Force-Angriffe bleibt jedoch, mit einem recht hohen Erfolgsgrad, bestehen.4.5 Heap-SchutzÜberblickWie in Abschnitt 3.1.6 beschrieben, kann es auch auf dem Heap zu Buffer-Overflows kommen. Umden Schaden begrenzen zu können, wurden mit dem SP2 von Windows XP im Wesentlichen zweineue Features, für die von Windows bereitgestellte Heap-Verwaltung, eingeführt: [ 8 ]  Cookies auf dem Heap (vergleichbar mit denen der GS-Funktionalität des Stacks)  Plausibilitätsprüfung (sanity checking) der Headerinformationen der einzelnen Heap- SegmenteFunktionsweise CookiesBei jedem Aufruf von HeapAlloc() wird vor und nach jedem Puffer auf dem Heap ein 1-Bytegroßes, mit Pseudo-Zufallszahlen initialisiertes Cookie, abgelegt. [ 8 ]Im Betrieb wird vor jedem Entnehmen eines Blocks aus der "Frei-Liste" geprüft, ob der Wert desCookies noch der Selbe ist, wie zum Zeitpunkt der Initialisierung. Dazu wird der Wert mit dem desseparat gespeicherten Original-Cookies verglichen. Hat sich der Wert geändert, so wird zuerst einHeapDestory() ausgeführt und anschließend wird eine Exception geworfen. Falls diese nichtbehandelt wird, wird das Programm beendet. [ 8 ]Außerdem wurde ein sogenannter Low Fragmentation Heap (LFH) entwickelt, der Primär derPerformancesteigerung dient. Dieser LFH ist ebenfalls durch ein Cookie geschützt. Allerdings durcheins der Größe 4-Byte. Durch das größere Cookie, wird das erraten des Werts und dieWahrscheinlichkeit für erfolgreiche Brute-Force-Angriffe, stark reduziert. [ 17 ]Funktionsweise PlausibilitätsprüfungDie "Frei-Listen" sind als doppelt verkette Listen aufgebaut. Die Pointer, die zur Verkettung der Listein beide Richtungen dienen, nennen sich Blink, für das vorhergegangene Element und Flink, für dasnächste Element. [ 8 ] Seite - 38 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaVor jedem Entnehmen eines Blocks aus der "Free-List" werden Blink und Flink auf ihre Plausibilitäthin geprüft. Das bedeutet, es wird geprüft, ob der der Blink aus dem Header des Folgeelements auchtatsächlich auf das aktuelle Element zeigt. Dieselbe Prüfung wird in die andere Richtung vollzogen.[8]SchwachstellenInnerhalb der Heap-Verwaltung gibt es nicht nur die oben genannten "Frei-Listen", sondern auchLookaside-Liste, die primär der Geschwindigkeitserhöhung dienen. Diese Listen sind nur einfachverkette Listen und aus diesem Grund könnten die Pointer nicht auf Plausibilität hin geprüft werden..Da aber unter XP mit SP2 der PEB und der Heap dynamische Startadressen haben, benötigt ein Brute-Force-Angriff nach mehr wie 2000 Versuche, vorausgesetzt die Applikation läuft nach einemfehlgeschlagenen Versuch weiter. [ 17 ]Eine weitere Schwachstelle ist das nur 1-Byte große Cookie und die in Abschnitt 4.4 beschriebene,schwache Zufallswahl des PEB-Speicherortes. Hinzu kommt noch die Tatsache, dass der LFH unterWindows XP SP2 standardmäßig von keiner Applikation verwendet wird. [ 17 ]Einen weiteren Angriff auf das Heap-Management beschreibt Alexander Anisimov. Dabei nutzt er dieTatsache, dass die Cookie-Prüfung und die Plausibilitätsprüfung der Pointer nur unter bestimmtenUmständen stattfinden. So ist es Alexander Anisimov, unter einer Reihe von Voraussetzungenmöglich, die Blink- und Flink-Pointer derart zu manipulieren, dass ein wahlfreier Schreibzugriff von1016 Bytes möglich ist. Die Voraussetzungen für diese Art von Angriff sind jedoch derart exotisch,dass Microsoft an dieser Stelle keinen unmittelbaren Handlungsbedarf sieht. [ 8 ]Eine etwas robustere Methode, als die von Alexander Anisimov, beschreibt Nicolas Falliere in [ 15 ] .Dabei ist das Prinzip das gleiche: Es werden Blink- und Flink-Pointer überschrieben, dadurch kommtes zu einem wahlfreien Schreibzugriff der Größe von 4-Byte. Dabei unterliegt dieser Angriff aber dengleichen Problemen wie der Angriff, auf die einfach verketteten Lookaside-Listen. Es ist also auch hiernur ein Brute-Force-Angriff möglich. [ 15 ]Nach [ 31 ] werden die Lookaside-Listen in den aktuellen Windows-Versionen nicht mehr verwendet,wodurch auf ihnen basierende Angriffe nicht mehr möglich sind.Effektiver SchutzUnter Windows XP mit SP1 war es aufgrund der fixen Speicherorte des PEB und des Heaps, sowie desFehlens, der oben beschrieben Neuerungen, möglich zuverlässige Remote-Exploits zu schreiben [ 17 ]Mit Windows XP SP2 wurden Maßnahmen eingeführt, die das Entwickeln zuverlässiger Exploitsdeutlich erschwert haben. Dennoch sind Brute-Force-Angriffe weiterhin möglich.Hinweis: Die in diesem Abschnitt beschriebenen Schwachstellen und Verbesserungen beziehen sichausschließlich auf das Heap-Management von Windows. Programme die ihr eigenes Heap- Seite - 39 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaManagement implementieren, profitieren von keiner der hier vorgestellten Neuerungen. Der Heap-Schutz wurde von Microsoft dennoch durch andere, in diesem Dokument vorgestellteSicherheitsfunktionen, stark verbessert. Zu nennen sind in diesem Zusammenhang vor allem DEP,SafeSEH und ASLR (Vista).Insgesamt hat sich die Gefahr durch Heap-basierende Angriffe stark verringert. So dass sich Angriffezukünftig verstärkt auf Anwendungsdaten konzentrieren werden, die auf dem Heap liegen (freiübersetzt nach [ 9 ] ).4.6 Visual Studio 2005 - Der "Windows-Compiler"Wie jedes andere Programm auch, müssen die Quelldateien eins Betriebssystems mit einemCompiler in ausführbare Dateien übersetzt werden. Im Falle von Windows kommt bei MicrosoftVisual Studio (VS) zum Einsatz [ 32 ] .Im Folgenden werden die, für Buffer-Overflows relevanten, Funktionen von VS 2005 vorgestellt undmit den Verbesserungen gegenüber früher Schutzfunktionen verglichen. Der Focus wird hierbei aufVS 200510 liegen, da dies der Compiler ist, mit dem das Betriebssystem Windows Vista übersetztwird. Außerdem wird der effektive Nutzen der Maßnahmen diskutiert.4.6.1 Standard Annotation Language (SAL)Option Beschreibung [ 33 ] Standard Windows Binaries/analyze Codeanalyse in der Enterprise-Version - Windows Vista(Compiler)ÜberblickSAL dient der Compiler gestützten Qualitätssicherung des Codes und ist in den Versionen "TeamSystem" und "Team Edition" von VS 2005 mittels der Option /analyze verfügbar. Ihr Ziel ist es demEntwickler beim Übersetzen seiner Programme Hinweise zu geben, an welcher Stelle derProgrammcode möglicher weise nicht so arbeitet wie erwartet. Die Hauptaufgabe von SAL ist esdabei, auf potentielle Buffer-Overflows aufmerksam zu machen. [ 31 ] [ 34 ]10 In den verwendeten Quellen ist häufig die Rede von dem „Whidbey-Compiler“. Whidbey ist der Codenamefür Visual Studio 2005 Seite - 40 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaFunktionsweiseBeim Erstellen des Quellcodes muss der Programmierer sogenannte Annotations in seinen Codeeinbringen. Zum Beispiel die Annotation __out_ecount, wie in folgendem Beispiel zu sehen ist:void FillString( __out_ecount(cchBuf) TCHAR* buf, size_t cchBuf, char ch) { for (size_t i = 0; i < cchBuf; i++) { buf[i] = ch; }}Quelle: [ 34 ]Beim Kompilieren mit der /analyse Option wird VS in diesem Beispiel folgende Ausgabe erstellen:c:codesaltestsaltest.cpp(54) : warning C6203: Buffer overrun for non-stack buffer b incall to FillString: length 420 exceeds buffer size 400c:codesaltestsaltest.cpp(54) : warning C6386: Buffer overrun: accessing argument 1, thewritable size is 200*2 bytes, but 420 bytes might be written: Lines: 53, 54c:codesaltestsaltest.cpp(54) : warning C6387: argument 1 might be 0: this does notadhere to the specification for the function FillString: Lines: 53, 54Quelle: (43)Dabei gibt es eine Reihe weiterer Annotations, die der Programmierer in seinen Code verwendenkann.Da die ursprüngliche Hauptaufgabe von SAL darin bestand Buffer zu beschreiben, auf die lesend undschreibend zugegriffen wird, versehen die Entwickler von Windows Vista alle entsprechendenFunktionen mit Annotations, bevor das Produkt an den Kunden ausgeliefert wird. [ 34 ]SchwachstellenDa SAL eine Meta-Sprache ist, die zur Unterstützung von statischen Analysetools entwickelt wurde,können dem entsprechend nur Fehler gefunden werden, die beim Kompilieren erkennbar sind.Buffer-Overflows, die zur Laufzeit auftreten, weil die Puffergröße beispielsweise von einerBenutzereingabe abhängt, können nicht erkannt werden. [ 34 ] Seite - 41 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaEffektiver NutzenDurch die Verwendung von SAL ist der Programmierer gezwungen sich mehr Gedanken über denAblauf seiner Funktionen zu machen. Zusammen mit einer konsequenten Anwendung und derBerücksichtigung der Compilerwarnungen, hätten mit SAL bereits in der Vergangenheit einige Buffer-Overflows vermieden werden können.Da SAL eine automatisierte Neuerung zur Verbesserung der Code-Qualität ist, ist SAL eine effektiveMaßnahme gegen die Entstehung von Sicherheitslücken.4.6.2 Optimierte Anordnung von Stack-Elementen (O2)Option Beschreibung [ 33 ] Standard Windows Binaries/O2 Erstellt schnellen Code. bei Release-Build Theoretisch alle(Compiler)ÜberblickSeit VS 2003 wird, beim Erstellen eins Release-Builds11, die Anordnung von Variablen (Puffern) aufdem Stack optimiert. Dabei ist es das Ziel potentiell verwundbare Puffer an einer ungefährlicherenPosition anzulegen [ 35 ] .FunktionsweiseWie auf der Abbildung 4-2 zu erkennen ist, wird die lokale Variable auth_flag, vor dem potentiellverwundbaren Puffer im Speicher angelegt. Da der Schreibzugriff immer nur in Richtung größerwerdender Adressen stattfindet, ist die Variable auth_flag in Sicherheit. Dasselbe Verfahren wirdauch bei dem Anlegen von Pointer angewendet.11 Standardmäßig ist bei dem Profil „Release“, in Visual Studio, die Compiler-Option O2 aktiviert Seite - 42 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Stackframe Stackframe Quellcode Ohne Mit Optimierung Optimierung 0000000h int check_authentication(char *password) { (Kleine Adressen) int auth_flag = 0; char password_buffer[8]; password_buffer: char[32] auth_flag: int Wachstumsrichtung strcpy(password_buffer, password); Overflowrichtung auth_flag: int password_buffer: char[32] if(strcmp(password_buffer, "password") == 0) auth_flag = 1; if(strcmp(password_buffer, "adminpw") == 0) Stack Frame Pointer (SFP) Stack Frame Pointer (SFP) auth_flag = 1; Return Adresse (RET) Return Adresse (RET) return auth_flag; } Parameter Parameter FFFFFFFFh (Große Adressen)Abbildung 4-2: Optimierte Anordnung von Stack-Elementen bei VS 2003Effektiver SchutzDurch dieses Verfahren wird zwar der Schutz, von lokalen Variablen und Pointern, vor Buffer-Overflows gewährt. Nicht geschützt sind diese Ziele jedoch vor Buffer-Underruns12.Die größte Gefahr bleibt nach wie vor bestehen. Wie in der Abbildung 4-2 zu sehen ist, ist es immernoch möglich, ausgehend von dem verwundbaren Puffer, die Returnadresse (RET) zu überschreibenund so beliebigen Code zur Ausführung zu bringen. Kombiniert mit den im Folgenden vorgestelltenMechanismen ergibt sich dennoch ein echter Mehrwert durch diese Optimierungen.4.6.3 Puffer-Sicherheitsüberprüfung (GS)Option Beschreibung [ 33 ] Standard [ 35 ] Windows Binaries [ 32 ]/GS Puffer-Sicherheitsüberprüfung aktiviert teilweise bei(Compiler) seit VS 2005 XP SP2, Vista/GS- Puffer-Sicherheitsüberprüfung deaktivieren deaktiviert teilweise bei(Compiler) seit Visual C++ 2002 XP SP2, Vista12 Zu einem Buffer-Underrun kann es beispielsweise durch fehlerhafte Pointerarithmetik kommen Seite - 43 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaÜberblickHinter dem Compilerswitch /GS verbirgt sich eine Funktion namens Buffer Security Check. DasHaupt-Ziel dieser Funktion ist es, ein Überschreiben der Return-Adresse zu erkennen und dasProgramm gegebenenfalls abzubrechen. Unter Linux gibt es mit StackGuard und ProPolice Lösungen,die diesem Prinzip ebenfalls folgen.Verfügbar ist diese Option seit Visual C++ 2002 und standardmäßig aktiviert ist die Option seit VS2005[ 35 ] . Dabei gilt es allerdings zu beachten, dass sich die Implementierungsdetails und damit dereffektive Schutz, seit der ersten Version stark verändert haben. Im Folgenden wird nur auf dieImplementierung von VS 2005 eingegangen.Seit Windows XP SP2 bzw. Windows Server 2003 ist die Option auch in den meisten Windows-Binaries Standard. [ 32 ]FunktionsweiseProgramme, die mit der /GS Option kompiliert wurden, initialisieren nach dem Programmstart 4Bytegroßes Master-Cookie, mit nicht vorhersagbarem Inhalt. Wird anschließend im Programmverlauf einegeschützte Funktion aufgerufen, so wird innerhalb des Funktionsprologs eine Kopie des Master-Cookies, wie auf Abbildung 4-3 zu sehen, auf dem Stack platziert. Wichtig ist hierbei vor allem diePosition des Cookies auf dem Stack: es liegt nach den potentiell verbundbaren lokalen Variablen undvor der Return-Adresse. Hat die Funktion ihre Arbeit erledigt, so wird innerhalb des Funktionsepilogsder momentane Wert, des auf dem Stack liegenden Cookies, mit dem Master-Cookie verglichen.Sollte innerhalb der Funktion ein Buffer-Overflow vorgekommen sein, der bis zu dem Cookie reicht,so wird das an dieser Stelle erkannt. Gegebenenfalls wird anschließend eine Ausnahme geworfenund falls diese nicht entsprechend behandelt wird, wird das Programm wird mit einer Fehlermeldungabgebrochen. [ 32 ] Seite - 44 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Beispielhaftes Stackframe 0000000h (Kleine Adressen) Gespeicherte Register der aufgerufenen Funktion Overflowrichtung Wachstumsrichtung Sichere Parameter Lokale Variablen Exception Handler Cookie FFFFFFFFh (Große Adressen) Stack Frame Pointer (SFP) Return Adresse (RET) Verwundbare ParameterAbbildung 4-3: Beispielhaftes Stacklayout unter Verwendung von /GS bei VS 2005 [ 32 ]Ebenfalls auf Abbildung 4-3 zu sehen, ist ein Feld "Sichere Parameter". Diese Neuerung gibt es seitVisual Studio 2005 und soll verhindern, dass durch verwundbare Funktionsparameter nachfolgendeSpeicherbereiche überschrieben werden können. Aktiviert wird diese Funktionalität ebenfalls mit der/GS Option. Dabei stellen die sicheren Parameter nichts weiter dar, wie eine Kopie der Original-Parameter. Während des Funktionsablaufs wird ausschließlich mit der Kopie (den sicherenParametern) gearbeitet. Aufgrund ihrer Position auf dem Stack, kann durch das weiter untenliegende Cookie, ein von dem Parametern ausgehende Buffer-Overflow ebenfalls erkannt werden. [32 ]SchwachstellenDie offensichtlichste und auch von Microsoft offiziell dokumentierte Schwachstelle, ist die Tatsache,dass das Cookie nur unter bestimmten Umständen angelegt wird. Begründet wird dieses Verhaltenvor allem durch den Overhead, der durch das zusätzliche Verwalten und Prüfen der Cookies entsteht.Das bedeute praktisch, dass ein Prüfung mittels Cookie, unter folgenden Umständen trotz aktivierter/GS Option nicht erfolgt: [ 33 ] [ 32 ]  Bei Funktionen, die keinen Puffer enthalten  Wenn die /O Optionen (Code optimieren) nicht aktiviert werden  Bei Funktionen mit variabler Argumentliste (...)  Bei Funktionen, die mit naked (C++) markiert sind  Bei Funktionen, die Inlineassemblycode in der ersten Anweisung enthalten Seite - 45 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista  Wenn ein Parameter nur auf eine Art und Weise verwendet wird, die im Falle eines Pufferüberlaufs höchstwahrscheinlich nicht ausgenutzt werden kannPassend zu dem letzten Punkt, wurde erst kürzlich herausgefunden, dass Puffer von einer Größekleiner wie 5 Byte offenbar als nicht gefährlich eingestuft werden und somit keinen Schutz durchCookies besitzen. [ 32 ]Die meisten der obigen Fälle kann der Entwickler glücklicher weise eliminieren, indem er das Pragmastrict_gs_check(on) verwendet [ 4 ] . Allerdings sollte bei diesem Vorgehen der zusätzlicheOverhead und die damit einhergehenden Performanceeinbußen nicht außer Acht gelassen werden.Falls der Angreifer die Möglichkeit hat, einen wahlfreien Schreibzugriff der Größe 4-Byteauszuführen, bevor der Cookie-Check durchgeführt wird, kann versucht werden das Master-Cookiemit einem bekannten Wert zu überschreiben. Da es in der aktuellen Implementierung nur 256mögliche Positionen für das Cookie gibt und der Speicherbereich beschreibbar ist, bieten sich hierBrute-Force-Angriffe an. [ 32 ] [ 36 ]Die gefährlichste Schwachstelle bei der Verwendung von /GS ist die Tatsache, dass man wie in derAbbildung 4-3 zu sehen ist, von einem verwundbaren Puffer ausgehend ohne weiteres den ExceptionHandler überschreiben kann. Wie in dem Abschnitt 3.1.5 kann dabei der Exception Handler anstelleder Return-Adresse überschrieben werden. Diese Methode funktioniert deshalb, weil die Funktionzum Prüfen des Cookies erst am Ende der Funktion aufgerufen wird. Bis dies geschieht kann einAngreifer eine Exception auslösen und somit die Ausführung des manipulierten Exception Handlerveranlassen[ 36 ] . Dieser Angriffsmöglichkeit begegnet VS mit der Einführung von SafeSEH auf dasspäter noch eingegangen wird.Effektiver Schutz/GS für sich allein bringt kaum einen Mehrwert, da durch das Manipulieren des Exception Handlersweiterhin alle Möglichkeiten offen stehen (Windows XP SP1, Windows Server 2003 SP0, Vista).In Verbindung mit SafeSEH (siehe nächster Abschnitt) jedoch, ist Microsoft hier ein sehr effektiverSchutzmechanismus gelungen, der den Stack für Angreifer zunehmend uninteressanter werden lässt.Wie eine aktuelle Studie von Symantec [ 32 ] zu dem Thema zeit, werden jedoch bei weitem nichtalle ausführbaren Windows-Dateien von Windows XP und Vista mit der /GS Option kompiliert. Dabeiexistiert bereits eine Liste mit Dateien, die ohne /GS Kompiliert wurden und somit nicht geschütztsind. Außerdem wurde von Symantec, zur Erstellung der besagten Liste, ein Programm entwickelt,dass in der Lage ist zu erkennen, ob ein Binary mit /GS kompiliert wurde. Mit diesen Hilfsmitteln sindAngriffe auf ungeschützte Dateien bereits vorprogrammiert.Dateien die mit /GS kompiliert wurden und zusätzlich zu dem eigentlichen Buffer-Overflow dieMöglichkeit eines wahlfreien 4-Byte-Schreibzugriffs bieten, sind aus den oben beschriebenen Grundanfällig für Brute-Force-Angriffe. [ 32 ] [ 36 ] Seite - 46 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaNicht vergessen werden darf bei diesem Mechanismus der Schadensbegrenzung jedoch, dass hierkeinerlei Schutz vor Denial of Service Angriffen (DoS)13 geboten wird.Abschließend sein noch darauf hingewiesen, dass die meisten Programme von Microsoft heutzutagemit /GS und /SafeSEH kompiliert werden.4.6.4 Sichere Ausnahmebehandlung (SafeSEH)Option Beschreibung [ 37 ] Standard Windows Binaries [ 4 ]/SAFESEH[:NO] Abbild verfügt über sichere Ausnahmehandler ? teilweise bei(Linker) Windows XP SP2, Windows Server 2003 SP1, Windows VistaÜberblickDie aktuelle Version der Linker-Option /SafeSEH wurde mit Windows XP SP2 / Server 2003 SP1eingeführt und ist nur für x86-Architekturen verfügbar[ 37 ] [ 4 ] . Ihr Ziel ist es, der im vorherigenAbschnitt angesprochene Möglichkeit, zum Umgehen der Cookie-Prüfung zu begegnen.Hinweis: Die genaue Geschichte des SAFESEH-Option ist etwas unklar: Eine Funktion zum validierengab es scheinbar bereits mit Server 2003 SP0, unklar ist allerdings welche Funktionalität wann undmit welchem Umfang eingeführt wurde.FunktionsweiseEin mit der /SafeSEH Option kompiliertes Programm, hat in dem Header der ausführbaren Datei(PE-Header) eine Liste "Sicherer Exception Handler". Wenn im Verlauf des Programms eineAusnahme ausgelöst wird, so prüft die Laufzeitumgebung, ob der auf dem Stack liegende, zurAusführung vorgesehene, Exception Handler in der besagten Liste steht. Sollte im Programmverlaufder Exception Handler manipuliert worden sein, so wird dies von Windows erkannt und dasProgramm wird abgebrochen. [ 4 ]13 Ziel von Denial of Service Angriffen ist es, einen Service oder Dienst für den Nutzer unverfügbar zu machen. Seite - 47 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaSchwachstellenWindows kann einen Exception Handler nur auf seine Richtigkeit überprüfen, wenn das Programmmit der /SafeSEH Option kompiliert wurde. Dementsprechend sind alle DLLs und Programme vonDrittherstellern, die diese Option nicht verwenden weiterhin verwundbar. [ 14 ]Effektiver SchutzZum Zeitpunkt der Analyse von Ben Nagy [ 14 ] im September 2006, waren keinerlei Möglichkeitenbekannt, bei Binaries die mit /GS und /SafeSEH kompiliert wurden, die Return-Adresse oder denException Handler als zuverlässigen Einstiegspunkt zu nutzen, um beliebigen Code zur Ausführung zubringen. [ 14 ]Die Ansätze zum Angriff, auf die im letzten Abschnitt vorgestellten Cookies, bleiben jedoch weiterhinbestehen und bieten einen Ansatzpunkt für weitergehende Analysen.Auch bei diesem Mechanismus der Schadensbegrenzung darf nicht vergessen werden, dass hierkeinerlei Schutz vor Denial of Service Angriffen geboten wird.4.6.5 Data Execution Prevention (DEP)Option Beschreibung [ 37 ] Standard [ 37 ] Windows Binaries/NXCOMPAT[:NO] Gibt an, dass eine ausführbare Datei mit dem wenn die teilweise bei(Linker) Windows-Feature Komponente Windows XP SP2, Datenausführungsverhinderung kompatibel ist. Vista erfordert Windows Server 2003 SP1, Windows VistaÜberblickDas Ziel von Hardware-DEP (Hardware-enforced DEP) ist es, Angreifern die Möglichkeit zu nehmen,eingeschleusten Code von beliebigen Speichersegmenten ausgehend, ausführen zu können. Dabei istes bisher historisch bedingt gewesen, dass auf dem Stack und dem Heap liegende Daten ausgeführtwerden können, obwohl dies bei entsprechender Programmierung eigentlich nicht nötig ist.Sollte bei Verwendung von Hardware-DEP dennoch versucht werden Code von einem als nichtausführbar markierten Bereich auszuführen, so wird eine Exception geworfen und falls diese nichtabgefangen wird, wird das Programm beendet. [ 38 ] Seite - 48 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaAußer dem Hardware-DEP gibt es auch ein Software-DEP (Software-enforced DEP). DieNamensgebung ist dabei nicht unbedingt logisch. Software-DEP wird nämlich bereits unter demSchlagwort SafeSEH geführt und hat es lediglich zum Ziel, Exception Handler auf Manipulationen hinzu prüfen und das Programm gegebenenfalls abzubrechen (siehe Abschnitt 4.6.4). Software-DEPkann in diesem Zusammenhang als eine Art Erweiterung zu Hardware-DEP gesehen werden. FürSoftware-DEP ist keine spezielle Hardware-Unterstützung notwendig. [ 38 ] [ 39 ]DEP ist seit Windows XP SP2 und Windows Server 2003 SP1 standardmäßig aktiviert. Hierbei sindsowohl Software-DEP, als auch Hardware-DEP inbegriffen. [ 38 ]FunktionsweiseDamit Hardware-DEP funktioniert wird ein Prozessor mit entsprechender Funktionalität benötigt. BeiAMD heißt die entsprechende Funktion "no-execute" (NX), bei Intel "Execute Disable" (XD). [ 39 ]Außerdem muss in der Datei Boot.ini bei 32-Bit-Systemen die Physical Address Extension (PAE)aktiviert sein. Bei 64-Bit-Windows-Versionen ist PAE nicht nötig, weil die entsprechendeFunktionalität bereits nativ implementiert ist.Software- und Hardware-DEP werden global mit dem Eintrag /noexecute=policy_level in derBoot.ini konfiguriert. Dabei gibt es für policy_level folgende vier Einstellungsmöglichkeiten: [ 39 ] 1. OptIn: Ist unter Windows XP SP2 die Standardkonfiguration. Mit dieser Option gilt die Datenausführungsverhinderung standardmäßig nur für Windows-Systembinärdateien. [ 39 ] 2. OptOut: Ist unter Windows 2003 Server SP1 [ 40 ] die Standardkonfiguration. Datenausführungsverhinderung standardmäßig für alle Prozesse aktivieren. Es kann über Registryeinträge, eine Liste mit Ausnahmen erstellt werden. [ 39 ] 3. AlwaysOn: Datenausführungsverhinderung gilt für das gesamte System. [ 39 ] 4. AlwaysOff: Für das gesamte System deaktivieren. [ 39 ]Außer über die globalen Einstellungen, lässt sich DEP für DLLs auch mittels eins "Incompatible-Flags"deaktivieren. [ 40 ]Eine dauerhafte Aktivierung von DEP lässt sich mit der oben angegebenen Compiler-Option/NXCOMPAT:YES erreichen [ 31 ] .Im Betrieb wird bei Hardware-DEP für jede virtuelle Speicherseite ein Bit gesetzt, dass denSpeicherbereich entweder als ausführbar oder nicht ausführbar markiert. Wird im Betrieb von einemals "nicht ausführbar" markierten Speicherbereich Code ausgeführt, so wird eine Exception geworfenund falls sie nicht behandelt wird, wird der Prozess beendet. Seite - 49 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaSchwachstellenIm Wesentlichen haben alle Schwachstellen, die mit DEP in Zusammenhang gebracht werden, mitdem Tradeoff zwischen Sicherheit und Kompatibilität zu tun, den Microsoft bei der Implementierungvon Hardware-DEP gegangen ist.So werden in der Regel weder der Internet Explorer 7, noch Java unter Windows Vista SP1 / XP SP2mit Hardware-DEP betrieben. Dadurch gelang es Shane Macauly und Alexander Sotrov im Rahmendes Wettbewerbs "Pwn to Own" im April 2008 mittels Flash und Java, Hardware-DEP zu umgehenund beliebigen eingeschleusten Code auszuführen. Diese, in Flash begründete Einstiegsmöglichkeit,wurde bereits 6 Tage nach dem Bekanntwerden von Adobe behoben. [ 41 ] [ 42 ]Eine weitere Schwachstelle von Hardware-DEP wurde bereits im Jahr 2005 gefunden [ 40 ] . Beidieser Methode nutzt der Angreifer die Möglichkeit, das Kompatibility-Flag vom User-Mode ausnachträglich ändern zu können. Dabei muss es dem Angreifer allerdings bereits möglich sein, im Stilvon return2libc eigenen Code ausführen zu können. Außerdem benötigt er die Adressen mehrererSpeicherregionen, die gezielt manipuliert werden müssen. Aufgrund der letzen Anforderung sindAngriffe dieser Art unter Windows Vista nicht mehr zuverlässig möglich, da dort ASLR zur Verfügungsteht. Microsoft hat auf die Veröffentlichung des Angriffs von Alexander Anisimov mit der Aussagereagiert, man glaube nicht, dies sei eine Schachstelle, weil der Angreifer bereits Code zur Ausführungbringen können muss. Abgesehen davon sei DEP auch primär zum Schutz vor Remote-Angriffenentwickelt worden. [ 43 ] [ 44 ]Effektiver SchutzDie Implementierung von DEP scheint, in Hinsicht auf Remote-Angriffe, bisher keine Schwachstellenzu haben. Wünschenswert wäre es dennoch, die oben angesprochenen Unzulänglichkeitenschnellstmöglich zu korrigieren, um so potentiellen neuen Angriffen so schwer wie möglich zumachen.Eine wirkliche Gefahr stellt die Abwärtskompatibilität von DEP dar. Hier sind die Drittherstellergefragt: Sie sollten schnellstmöglich sicherstellen, dass alle Ihre Produkte mit aktivierten Hardware-DEP uneingeschränkt lauffähig sind. Seite - 50 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista4.6.6 Address Space Layout Randomization (ASLR)Option Beschreibung [ 37 ] Standard[ 4 ] Windows Binaries [ 31 ]/DYNAMICBASE[:NO] Address Space Layout Randomization verfügbar und Windows Vista(Linker) Standard seit seit Beta2 VS 2005 SP1ÜberblickASLR ist eine Funktionalität, die ausschließlich unter Windows Vista zur Verfügung steht und seitVisual Studio 2005 SP1 auch für Eigenentwicklungen verfügbar ist. Das Ziel von ASLR ist es, Remote-Angriffe, die es zum Ziel haben eigenen Code zur Ausführung zu bringen, so unzuverlässig wiemöglich zu machen. Ausschließen lässt sich diese Art von Angriff mit ASLR nicht, da das Systemgrundliegend auf einen begrenzten Grad an Wahrscheinlichkeit zurückgreift. [ 30 ]FunktionsweiseWird bei VS 2005 SP1 /DYNAMICBASE als Option beim Linken angegeben, so wird im PE-Header derausführbaren Datei ein Flag gesetzt, dass der Laufzeitumgebung mitteilt, dass ASLR verwendetwerden soll. [ 30 ]Beim Bootvorgang von Windows Vista wird ein globales Image-Offset gewählt, von dem ausgehendalle DLLs geladen werden. Dadurch ist es weiterhin effizient möglich, innerhalb aller Prozesse aufeine gemeinsame Funktionalität einer DLL zuzugreifen. Außer dem globalen Image-Offset werden dieBasisadressen von der TXT-, DATA- und BSS-Segmente sowie der der DLLs, bei jedem Reboot neugewählt. Im Unterschied dazu, werden die Basisadressen des Stacks und der angelegten Heaps, beijedem Programmstart neu gewählt und sind für jeden Thread verschieden. Zusätzlich zu derBasisadresse des Stacks, wird der Initial-Stack-Pointer dynamisch gewählt. [ 30 ]Die Bestimmung der dynamischen Adressen erfolgt dabei durch Pseudo-Zufallszahlen. Die Menge dermöglichen Basisadressen ist dabei sehr unterschiedlich. So ist beispielsweise die Menge dermöglichen Adressen für den Initial Stack-Pointer auf einem 32-Bit-System 16.384, für dieBasisadresse des globalen Image-Offsets jedoch, existieren lediglich 256 Möglichkeiten. [ 30 ]Nichts direkt mit dem eigentlichen ASLR der Linker-Option /DYNAMICBASE, hat die in Abschnitt 4.4beschriebene dynamische Wahl des PEB zu tun. Dabei wird ebenfalls, bei jedem Programmstart, dieAdresse des PEB zufällig gewählt. Seite - 51 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaSchwachstellenDie offensichtlichste Schwachstelle von ASLR existiert bei lokalen Angriffen. Dabei muss ein Angreiferlediglich einen eigenen Prozess starten und mittels eines Debuggers die globale Basisadresseermitteln. Hierbei sollte allerdings berücksichtigt werden, dass ALSR primär zum Schutz vor Remote-Angriffen entwickelt wurde und somit ist es in der Regel nicht möglich, einen eigenen Prozess zustarten, von dem diese Information abgeleitet werden kann. [ 30 ]Eine wirkliche Schwachstelle hingegen ist die Tatsache, dass ähnlich wie bei GS und SafeSEH, nochnicht alle Windows Binaries mit der entsprechenden Option kompiliert wurden. Nach [ 4 ] sind beiWindows Vista Ultimate 1676 von 1767 Dateien mit ASLR kompiliert.Einer Analyse von Symantec zufolge[ 30 ] , bestehen in der Implementierung von ASLR noch einigeVerbesserungsmöglichkeiten. Im Wesentlichen wird dabei die Häufigkeitsverteilung derBasisadressen als verbesserungswürdig eingestuft. Die größte Schwachstelle in diesemZusammenhang betrifft die Basisadresse des PEB, die in 25% aller Fälle identisch ist. Außerdem zeigtsich bei der Verwendung von HeapAlloc() eine sehr deutliche Häufigkeitsverteilung. Ausgehendvon diesen Implementierungsschwächen bieten sich Brute-Force-Angriffe geradezu an. [ 30 ]Effektiver SchutzWie bereits erwähnt ist der Schutz vor lokalen Angriffen durch ASLR nahezu null.Die Möglichkeit zuverlässige Remote-Exploits zu schreiben, wurde durch ASLR signifikant verringert.Dabei bleibt jedoch die Möglichkeit der Brute-Force Angriffe bestehen. Dies könnte vor allem durchdie oben erwähnten Schwächen in der Häufigkeitsverteilung interessant werden. Da sich Microsoftdieser Problematik jedoch bewusst ist und dieses Problem selbst auf eineImplementierungsschwäche zurückführt, kann auf eine baldige Beseitigung dieser Unzulänglichkeitgehofft werden. [ 30 ]Auch bei diesem Mechanismus der Schadensbegrenzung darf nicht vergessen werden, dass hierkeinerlei Schutz vor Denial of Service Angriffen geboten wird.4.7 Abschließender Vergleich: XP gegenüber VistaWie sich der folgenden Tabelle entnehmen lässt, sind viele Neuerungen der jüngeren Vergangenheitauch in Windows XP enthalten. Diese Neuerungen für sich haben die Schwierigkeit zuverlässigeExploits zu schreiben, die auf Buffer-Overflows basieren, stark erhöht. Laut CVE-Statistik [ 1 ] gab esfür Windows XP im Jahr 2007 noch 28 veröffentliche Schwachstellen, die direkt auf Buffer-Overflowszurückzuführen waren. Im Jahr 2008 ist es, bis zum Druckzeitpunkt dieser Arbeit im Juni 2008, nochkeine einzige solche Schwachstelle. [ 1 ] Seite - 52 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaTabelle 1: Sicherheitsmechanismen in XP und Vista Windows XP Windows VistaUAC und Service Hardening Nein JaPatchguard Ja, Ja, nur bei 64Bit nur bei 64BitPEB Randomization Seit SP2 JaSAL Ja, Ja, bei entsprechender bei entsprechender Entwicklungsumgebung EntwicklungsumgebungStackoptimierungen(O2) Ja, Ja, muss beim Kompilieren muss beim Kompilieren aktiviert werden aktiviert werdenSafeSEH Seit SP2, Ja, muss beim Linken aktiviert muss beim Linken aktiviert werden werdenDEP Seit SP2, Ja, muss beim Linken aktiviert muss beim Linken aktiviert werden werdenASLR Nein Ja, muss beim Linken aktiviert werdenWeitere Neuerungen wie UAC und ASLR, die nur Windows Vista und seinen Folgeversionenzugänglich sind, haben den Sicherheitsstandard noch weiter erhöht, so dass Buffer-Overflows alsEinfallstor zunehmend unwahrscheinlicher werden. Außerdem schränken sie den Spielraum deseingeschleusten Codes stark ein, was ebenfalls einen sicherheitstechnischen Mehrwert darstellt.Im Fazit folgt nun eine kurze Zusammenfassung und eine Bewertung der Gesamtmenge anMaßnahmen, die in Windows XP und Windows Vista zum Einsatz kommen. Seite - 53 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista5 FazitIn den beiden ersten Kapiteln wurden einige traditionelle und einige neuere Angriffstechnikenvorgestellt, die auf Buffer-Overflows basieren und mit denen ein modernes Betriebssystemheutzutage zurechtkommen muss. In dem letzten Kapitel wurden die Mechanismen vorgestellt, dieWindows Vista und frühere Versionen mitbringen, um sich gegen diese Gefahren zu wappnen. Dabeiist es offensichtlich, dass Microsoft einen beachtlichen Entwicklungsaufwand investiert hat um denRuf des unsicheren "Blue-Screen-Windows" endgültig abzulegen.Dabei sind neue Programmierpraktiken wie SAL entstanden, die den Entwicklern helfen Buffer-Overflows erst gar nicht entstehen zu lassen und somit den wohl effektivsten Schutz gegen Buffer-Overflows bietet. Sollten sich im Code von Drittherstellern, oder im Betriebssystem selbst dennochBuffer-Overflows finden, so wird der praktische Nutzen, durch die meisten in diesem Dokumentvorgestellten Mechanismen, auf Denial of Service Angriffe reduziert. Dies gilt allerdings nur, wenn diegesamte Breite, an zur Verfügung stehenden Schutzmechanismen, verwendet wird. Das einfachsteNegativbeispiel ist ein Programm, das zwar mit /GS, aber nicht mit /SafeSEH kompiliert wurde. Hierverwendet der Angreifer einfach den Exception Handler und nicht die Rücksprungadresse alsEinstiegspunkt.Kritik und Lob zugleich verdient Windows Vista für seine Abwärtskompatibilität. So freut esDritthersteller, dass sie ihre Programme nicht aufwändig umschreiben müssen, um mit den neuenSicherheitsmechanismen kompatibel zu sein, denn sie bleiben einfach inkompatibel. Was denProgrammierer der Software freut, ist schlecht für die Gesamtsicherheit des Systems. Alsbekanntestes Negativbeispiel sei hier nochmals der Internet Explorer 7 genannt, der selbst heutenoch mit deaktivierten DEP das Tor zur Welt öffnet.Sollte es einem Anwender gelingen, nur Programme zu betreiben, die alle zur Verfügung stehendenMechanismen verwenden, so betreibt er das mit Abstand sicherste Windows-System das es bishergab.Dennoch ist "das sicherste" nicht gleichzusetzen mit "sicher". Dieser Tatsache ist sich auch StephenToulouse (Senior Product Manager bei Microsoft Security Technology) bewusst, der sagt: "Keins der Features aus Windows Vista, weder allein, noch zusammen, ist kugelsicher. Dennoch erhöht sich der Schutz gegenüber Windows XP signifikant" (Frei übersetzt nach [ 29 ] ).Aus dieser richtigen, aber auch sehr unverfänglichen Aussage, lässt sich ablesen, wie schwer es ist,den effektiven Schutz eines Betriebssystems zu beurteilen.Um die gesamte Sicherheit von Windows Vista zu bewerten darf man nicht nur veröffentlicheSicherheitslücken bewerten, sondern man muss auch Dienstleister, mit moralisch fragwürdigerMotivation in seine Bewertung mit einbeziehen, die versprechen gegen Bezahlung funktionierendeExploits zu liefern. Ebenso dürfen Hacker mit unterschiedlichen Idealen nicht vergessen werden, die Seite - 54 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vistateilweise kein Interesse daran haben ihre "private Exploits" zu veröffentlichen, da Sie dadurch ihren"Freiraum" verkleinern würden.Auch wenn sich abschließend nicht sagen lässt "Windows Vista ist sicher", der Mehrwert denNeuerungen wie UAC und ASLR gegenüber Windows XP bringen, ist unbestritten. Wer also vor derWahl steht XP oder Vista, dem sollte vom sicherheitstechnischen Standpunkt aus, auf jeden Fall zuVista geraten werden. Seite - 55 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaA Literaturverzeichnis1. Statistics. [Online] National Vulnerability Database, 15. 7 2008. http://nvd.nist.gov/.2. Mark E. Russinovich, David A. Solomon. Windows Internals. Redmond : Microsoft Corporation,2005. ISBN 3-86063-977-3.3. James C. Foster, Vitaly Osipov, Nish Bhalla, Niels Heinen. Buffer Overflow Attacks: Detect, Exploit,Prevent. Rockland : Syngress Publishing, Inc., 2005. ISBN 1-932266-67-4.4. Joel Scambray, Stuart McClure. Hacking Exposed Windows: Windows Security Secrets & Solutions,Third Edition. s.l. : McGraw-Hill, 2008. ISBN 978-0-07-149426-7.5. Ericson, Jon. HACKING: THE ART OF EXPLOITATION, 2ND EDITION. San Francisco : NO STARCHPRESS, 2008. ISBN 978-1-59327-144-2.6. Know-how: Heap-Verwaltung Haufenakrobatik. Stiller, Andreas. 4, Hannover : Heise ZeitschriftenVerlag GmbH & Co. GK, 2007. ISSN 0724-8679.7. Pufferüberläufe auf dem Heap und wie man sie ausnutzt. Lindner, Felix. 09, Hannover : HeiseZeitschriften Verlag GmbH & Co. GK, 2006. ISSN 0724-8679.8. Alexander Anisimov, Positive Technologies. Defeating Microsoft Windows XP SP2 Heap protectionand DEP bypass. [Online] 2004. [Zitat vom: 5. 4 2008.] http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm.9. Horovitz, Matt, Conover und Oded. Windows Heap Exploitation. [Online] [Zitat vom: 5. 4 2008.]http://www.cybertech.net/~sh0ksh0k/projects/winheap/XPSP2%20Heap%20Exploitation.ppt.10. Kallnik, Stephan, et al. Buffer-Overflows und andere Sollbruchstellen. heise Security. [Online] 30.6 2003. [Zitat vom: 1. 4 2008.] http://www.heise.de/security/Buffer-Overflows-und-andere-Sollbruchstellen--/artikel/37958/2.11. Visual C++ Referenz. msdn. [Online] Microsoft Corporation. [Zitat vom: 17. 5 2008.]http://msdn2.microsoft.com/de-de/library/de5awhsw.aspx.12. Using an Exception Handler (Windows). msdn. [Online] Microsoft Corporation. [Zitat vom: 29. 42008.] http://msdn2.microsoft.com/en-us/library/ms681409%28VS.85%29.aspx.13. Mangarae, Aelphaeis. SEH Overwrites Simplified v1.01. [Online] 27. 10 2007. [Zitat vom: 2. 42008.] http://www.milw0rm.com/papers/187.14. Nagy, Ben. SEH (Structured Exception Handling) Security Changes in XPSP2 and 2003 SP1.[Online] eEye Digital Security, 5. 12 2006. [Zitat vom: 16. 5 2008.]http://www.eeye.com/html/resources/newsletters/vice/VI20060830.html. Seite - 56 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista15. Falliere, Nicolas. Bypassing Windows heap protections. [Online] [Zitat vom: 11. 4 2008.]http://packetstormsecurity.org/papers/bypass/bypassing-win-heap-protections.pdf.16. Conover, Matt. Double Free Vulnerabilities. Vulnerabilities & Exploits. [Online] 1 2007. [Zitat vom:1. 5 2008.]http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa.html.17. Conover, Matt & Horovitz, Oded. Windows Heap Exploitation. [Online] 12 2004. [Zitat vom: 5. 42008.] http://www.cybertech.net/~sh0ksh0k/projects/winheap/XPSP2%20Heap%20Exploitation.ppt.18. Conover, Matt & w00w00 Security Team. w00w00 on Heap Overflows. [Online] 1 1999. [Zitatvom: 1. 4 2008.] http://www.w00w00.org/files/articles/heaptut.txt.19. c0ntex. Windows Heap Overflows using the Process Environment Block (PEB). [Online] [Zitat vom:6. 4 2008.] http://www.milw0rm.com/papers/66.20. Wana, Thomas aka. greuff. Writing UTF-8 compatible shellcodes. [Online] [Zitat vom: 2. 4 2008.]http://www.phrack.org/issues.html?issue=62&id=9.21. Tüllmann, Thorsten. Shellcode unter Windows, Linux und MacOS. [Online] 15. 2 2006. [Zitat vom:4. 5 2008.] http://www.tm.uka.de/itm/uploads/folien/88/08-Thorsten_Tuellmann-Shellcode.pdf.22. Kritische Lücke in Intels Centrino WLAN-Treibern. Heise Security. [Online] Heise ZeitschriftenVerlag GmbH & Co. GK, 2. 8 2006. [Zitat vom: 14. 5 2008.] Kritische Lücke in Intels Centrino WLAN-Treibern.23. Barnaby, Jack Senior. Remote Windows Kernel Exploitation - Step into the Ring 0. [Online] 2005.[Zitat vom: 14. 5 2008.] http://research.eeye.com/html/papers/download/StepIntoTheRing.pdf.24. Messier, Matt und Viega, John. Secure Programming Cookbook for C and C++. s.l. : OReilly, 2003.0-596-00394-3.25. Jesper M., Johansson. Sicherheit auf dem Prüfstand: Tools zum Verwalten von ACLs. TechNetMagazin. [Online] 2008. [Zitat vom: 16. 5 2008.] http://technet.microsoft.com/de-de/magazine/cc138006.aspx.26. Impact of Session 0 Isolation on Services and Drivers in Windows Vista. Windows HardwareDeveloper Central. [Online] 20. 12 2007. [Zitat vom: 16. 5 2008.]http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Session0_Vista.docx.27. Moore, Brett. Shattering By Example. [Online] 10 2003. [Zitat vom: 16. 5 2008.] http://security-assessment.com/files/whitepapers/Shattering_By_Example-V1_03102003.pdf.28. Skywing. PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3. [Online] 9 2007. [Zitatvom: 17. 5 2008.] http://www.uninformed.org/?v=8&a=5&t=txt. Seite - 57 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista29. Lemos, Robert. Vista raises the bar for flaw finders. [Online] 29. 1 2007. [Zitat vom: 17. 5 2008.]http://www.securityfocus.com/news/11439.30. Whitehouse, Ollie. An Analysis of Address Space Layout Randomization on Windows Vista™.[Online] 2007. [Zitat vom: 2. 4 2008.]http://www.symantec.com/avcenter/reference/Address_Space_Layout_Randomization.pdf.31. Hellen, Ian und Kumar, Vishal. Security Engineering in Windows Vista. HITBSecConf2006 -Malaysia. [Online] 18. 9 2006. [Zitat vom: 24. 5 2008.]http://packetstormsecurity.org/hitb06/DAY_1_-_Ian_Hellen_and_Vishal_Kumar_-_Security_Engineering_in_Vista.pdf.32. Whitehouse, Ollie. Analysis of GS protections in Microsoft Windows Vista. [Online] 2007. [Zitatvom: 18. 5 2008.] http://www.symantec.com/avcenter/reference/GS_Protections_in_Vista.pdf.33. Visual C++-Compileroptionen. msdn. [Online] [Zitat vom: 17. 5 2008.]http://msdn.microsoft.com/de-de/library/9s7c9wdw.aspx.34. Howard, Michael. A Brief Introduction to the Standard Annotation Language (SAL). MichaelHowards Web Log - A Simple Software Security Guy at Microsoft! [Online] 19. 5 2006. [Zitat vom: 27.5 2008.] http://blogs.msdn.com/michael_howard/archive/2006/05/19/602077.aspx.35. Branbray. Security Improvements to the Whidbey Compiler. http://blogs.msdn.com/. [Online] 11.11 2003. [Zitat vom: 17. 5 2008.] http://blogs.msdn.com/branbray/archive/2003/11/11/51012.aspx.36. Litchfield, David. Defeating the Stack Based Buffer Overflow Prevention Mechanism of MicrosoftWindows 2003 Server. [Online] 8. 9 2003. [Zitat vom: 2. 4 2008.]http://www.nextgenss.com/papers/defeating-w2k3-stack-protection.pdf.37. Visual C++-Linkeroptionen. msdn. [Online] [Zitat vom: 18. 5 2008.]http://msdn.microsoft.com/de-de/library/y0zzbyt4.aspx.38. How to Configure Memory Protection in Windows XP SP2. Microsoft TechNet. [Online] 9. 122004. [Zitat vom: 24. 5 2008.]http://www.microsoft.com/technet/security/prodtech/windowsxp/depcnfxp.mspx.39. A detailed description of the Data Execution Prevention (DEP) feature in Windows XP ServicePack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003. Hilfe und Support. [Online]26. 10 2006. [Zitat vom: 24. 5 2008.] http://support.microsoft.com/?scid=kb%3Ben-us%3B875352&x=1&y=8.40. skape und Skywing. Bypassing Windows Hardware-enforced Data Execution Prevention.Uninformed - vol 2 article 4. [Online] 10 2005. [Zitat vom: 25. 5 2008.]http://www.uninformed.org/?v=2&a=4. Seite - 58 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista41. Erste Hintergründe zum Flash-Hack beim PWN-to-OWN-Wettbewerb. heise Security. [Online] 3. 42008. [Zitat vom: 24. 5 2008.] http://www.heise.de/security/Adobe-schliesst-sieben-Luecken-im-Flash-Player--/news/meldung/106237.42. Adobe schließt sieben Lücken im Flash-Player. heise Security. [Online] 9. 4 2008. [Zitat vom: 25. 52008.] http://www.heise.de/security/Adobe-schliesst-sieben-Luecken-im-Flash-Player--/news/meldung/106237.43. Microsoft: Fehler in Buffer-Overflow-Schutz ist keine Schwachstelle. heise online. [Online] 2. 22008. [Zitat vom: 25. 5 2008.] http://www.heise.de/newsticker/Microsoft-Fehler-in-Buffer-Overflow-Schutz-ist-keine-Schwachstelle--/meldung/55851.44. Buffer-Overflow-Schutz in Windows XP SP2 lückenhaft. heise Security. [Online] 31. 01 2005. [Zitatvom: 25. 5 2008.] http://www.heise.de/security/Buffer-Overflow-Schutz-in-Windows-XP-SP2-lueckenhaft--/news/meldung/55738.45. Stephan Kallnik, Daniel Pape, Daniel Schröter, Stefan Strobel. http://www.heise.de. heiseSecurity. [Online] 3. 6 2003. [Zitat vom: 1. 4 2008.] http://www.heise.de/security/Buffer-Overflows-und-andere-Sollbruchstellen--/artikel/37958/0.46. Howard, Michael. Windows Vista Security – A Bigger Picture. http://blogs.msdn.com. [Online] 12.6 2006. [Zitat vom: 17. 5 2008.]http://blogs.msdn.com/michael_howard/archive/2006/06/12/628207.aspx.47. One, Aleph. Smashing The Stack For Fun And Profit. [Online] [Zitat vom: 2. 4 2008.]http://www.phrack.org/issues.html?issue=49&id=14#article.48. skape. Understanding Windows Shellcode. [Online] 6. 9 2003. [Zitat vom: 31. 3 2008.]http://nologin.org/Downloads/Papers/win32-shellcode.pdf.49. talz. How-to exploit default exception handler to gain stability on win32. [Online] [Zitat vom: 16.5 2008.] http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability. Seite - 59 -
  • Stack- und Heap-Overflow-Schutz bei Windows XP und Windows VistaB QuellcodeDer Quellcode wurde aus Platzgründen in einen Zip-Archiv ausgelagert. Diese Zip-Datei, sowie dieaktuelle Version dieses Dokuments, sind unter folgender Adresse erhältlich:http://jssk.de/data/studienarbeit/Quellcode-Studienarbeit-BOs.zipSollten sich im Laufe der Zeit Änderungen ergeben, so dass der oben angegebenen Link nicht mehrfunktioniert, so bin ich unter folgender Kontaktadresse erreichbar.Kontaktadresse: JohannesHoh@googlemail.comInhalte des Qullecode-Archivs  Hinweise zum Kompilieren  Batchdateien zum Kompilieren mit Visual-Studio 2005 bzw. 2008  Quellcode zu dem Programmen  Beispielprogramme, fertig kompiliert  Beispielhafte Programmabläufe (Programmausgaben)  Perlskripte zum erstellen des Bytecodes  Beispielhaft erstellter Bytecode Seite - 60 -