Frage:
Sollte ich mir die Mühe machen, Pufferüberläufe nicht mehr zu lehren?
Fixee
2011-03-01 09:42:06 UTC
view on stackexchange narkive permalink

Die Schüler sind skeptisch, dass das Ausschalten nicht ausführbarer Stapel, das Ausschalten von Kanarienvögeln und das Ausschalten von ASLR eine realistische Umgebung darstellt. Wenn PaX, DEP, W ^ X usw. wirksam sind, um Pufferüberlauf-Exploits zu stoppen, ist es dann immer noch sinnvoll, etwas über sie zu lernen?

@Fixee Ich werde hier brutal ehrlich sein. Wenn Sie wirklich die Idee hinterfragen, Pufferüberläufe zu lehren, denke ich wirklich nicht, dass Sie eine Klasse über Sicherheit "unterrichten" sollten. Da Pufferüberläufe einer der grundlegendsten und universellsten Sicherheits-Exploits sind, sollten sie ein wesentlicher Bestandteil des Verständnisses und der Lehre sein, wie man ein System angreift.
@mrnap Ich unterrichte seit 13 Jahren Pufferüberläufe und Shellcode-Schreiben. Wie die meisten Leute im Sicherheitsbereich wissen, war dies einst die größte Sicherheitslücke (vor 5 bis 10 Jahren) und wurde seitdem durch andere Sicherheitslücken ersetzt. Ich habe die obige Frage gestellt, um Fachleute zu befragen, wie wichtig es ist, diese Techniken zu unterrichten (was viel Zeit in Anspruch nimmt), wenn andere Themen relevanter werden. Sie kritisieren mich dafür, dass ich überhaupt die Frage gestellt habe: Glauben Sie mir, wenn ich nicht ständig die Auswirkungen meines Unterrichts in Frage stelle, dann mache ich meinen Job nicht.
@Fixee Ich verstehe Ihren Standpunkt, aber ich denke immer noch, dass mein ursprünglicher Standpunkt darin besteht, dass sie ein grundlegender Aspekt der Ausbeutung sind. Jeder, der auf dem neuesten Stand ist und irgendetwas in der Branche liest oder die Sicherheit auf grundlegende Weise versteht, versteht, dass BOs existieren, solange eine schlechte Codierung vorliegt. Ich würde durch die Kakophonie von Ja denken, dass dies ziemlich offensichtlich wäre.
@mrnap Wir haben 10 Wochen Zeit, um eine Sicherheitsklasse zu unterrichten
@mrnap, ob die klare Antwort ein klares "JA" ist oder nicht, es ist * immer * eine legitime Frage zu stellen. Tatsächlich sollte jemand, der die derzeitige konventionelle Weisheit * nicht * ständig in Frage stellt, keine Klasse über Sicherheit unterrichten. Wie wir alle wissen, ist das Hinterfragen von Annahmen eines der besten Werkzeuge in unserer Toolbox und führt meistens dazu, dass Schwachstellen gefunden werden.
@avid schön gesagt! @mrnap, Bitte beachten Sie auch die tollen Ratschläge in unserer FAQ: * Seien Sie nett. Behandle andere mit dem gleichen Respekt, den sie von dir erwarten. * :)
Seit wann verwendet das Betriebssystem Ihres Autos PaX?Wann haben Sie das letzte Mal eine NIC-Firmware mit W ^ X gesehen?Haben Sie jemals einen MIPS32-Router mit DEP gesehen?Während große, aufgedunsene Desktops und Server möglicherweise über diesen Schutz verfügen, ** tun dies nicht alle modernen Geräte. **
Acht antworten:
#1
+49
ReinstateMonica Larry Osterman
2011-03-01 12:47:53 UTC
view on stackexchange narkive permalink

Auf jeden Fall. ASLR und DEP sind tiefgreifende Verteidigungsmaßnahmen. Es gibt Exploits, die jeden von ihnen umgehen können (ein Beispiel aus der Praxis finden Sie unter Peter Vreugdenhils Pwn2Own-Exploit, den er gegen IE verwendet hat).

Alles, was Sie brauchen Bypass ASLR für Windows ist eine Sicherheitsanfälligkeit bezüglich der Offenlegung von Informationen, mit der Sie die Basisadresse einer geladenen DLL im Prozess erfahren (dies war die erste Vuln, die Vreugdenhil ausnutzte). Von diesem Punkt aus können Sie einen Ret-to-Libc -Angriff verwenden, um eine beliebige Funktion in dieser DLL aufzurufen.

Das Fazit: Stapel- (und Heap-) Überläufe sind auch heute noch absolut relevant. Sie sind schwerer auszunutzen als früher, aber sie sind immer noch relevant.

In einigen spezifischen Kontexten können Pufferüberläufe aufgrund von [Speicherlayoutlecks, z. in Kerneln] (http://security.stackexchange.com/questions/69054/does-kaslr-really-provide-more-security-against-exploits). Heartbleed wurde auch durch einen Pufferüberlauf verursacht, und dies wird erneut vorkommen, da wir weiterhin Low-Level-Code für Hardwareschnittstellen und Betriebssystembibliotheken schreiben und weiter schreiben werden ...
#2
+18
AviD
2011-03-01 17:58:13 UTC
view on stackexchange narkive permalink

Neben den hervorragenden, präzisen Antworten von @ Larry und @ SteveS möchte ich auf einen sehr wichtigen Punkt hinweisen:

Die Schüler sind skeptisch, nicht ausführbare Stapel auszuschalten, Kanarienvögel auszuschalten und auszuschalten off ASLR repräsentiert eine realistische Umgebung.

Hoffentlich gilt dies für die Systeme Ihrer Schüler.
Im Rest der Welt ist dies jedoch leider immer noch sehr verbreitet. Neben den Plattformen, die diese nicht unterstützen, gibt es immer schlecht gebaute Produkte, bei denen diese abgeschaltet werden müssen, ältere Versionen des Betriebssystems und sogar nur schlechte Fehlkonfigurationen.
Trotzdem sehr realistisch, leider.

Hinzu kommen 2 weitere Kommentare von einem pädagogischen POV:
1. Jemand muss diese Verteidigung aufbauen, oder?
2. Auch wenn sie hypothetisch richtig waren - Sie benötigen nur Zeiger in C / C ++ bedeutet nicht, dass ein Java-Entwickler nicht lernen sollte, wie diese Dinge im Computer funktionieren, oder?

+1 für # 2. Auf jeden Fall eine dringend benötigte Ergänzung.
#3
+17
Thomas Pornin
2011-03-01 18:30:03 UTC
view on stackexchange narkive permalink

Ja. Abgesehen von den Systemen, in denen Pufferüberläufe zu erfolgreichen Exploits führen, sind vollständige Erklärungen zu Pufferüberläufen immer eine gute Möglichkeit, um zu demonstrieren, wie Sie über Sicherheit denken sollten. Anstatt sich darauf zu konzentrieren, wie die Anwendung ausgeführt werden soll, sollten Sie prüfen, was getan werden kann, um die Anwendung zu entgleisen.

Unabhängig von der Stapelausführung und der Anzahl der installierten schreienden Kanarienvögel ist ein Pufferüberlauf ein Fehler . All diese Sicherheitsfunktionen ändern einfach die Konsequenzen des Fehlers: Anstelle einer Remote-Shell kommt es "nur" zu einem sofortigen Anwendungsabsturz. Sich nicht um Anwendungsabstürze zu kümmern (insbesondere um Abstürze, die remote ausgelöst werden können), ist bestenfalls eine sehr schlampige Programmierung. Nicht auf meiner Uhr!

Der Vollständigkeit halber verhindern nicht ausführbare Stapel und Kanarienvögel keine Pufferüberläufe. Sie haben nur einige der einfachen Möglichkeiten zum Ausnutzen von Pufferüberläufen deaktiviert. Beim herkömmlichen Pufferüberlauf wird die Rücksprungadresse durch einen Zeiger auf schädlichen Code ersetzt, der als Teil der Daten geladen wird, die den Puffer überlaufen haben. Der Schadcode wird ausgeführt, wenn die Funktion zurückgegeben wird. Der nicht ausführbare Stapel bedeutet, dass der Angreifer seinen Code nicht auf dem Stapel platzieren kann (er muss einen Sprung in einen Bibliothekscode veranlassen, z. B. die Implementierung von execve () in der Standardbibliothek ). Der Kanarienvogel verhindert, dass die Rücksprungadresse verwendet wird, wenn ein Stapelpuffer übergelaufen ist (vorausgesetzt, der Überlauf ist "einfach": ein zusammenhängender Datenblock). Der Überlauf kann jedoch auch einige andere Daten überschreiben, einschließlich Funktionszeiger (insbesondere im Kontext von C ++).

Großartiger Beitrag, einige zusätzliche Punkte: 1. Die Leute müssen lernen, weniger fehlerhaften Code zu schreiben und sich nicht blind auf Schadensbegrenzungen zu verlassen (wie der Autor richtig angegeben hat, wurden die stapelbasierten Pufferüberläufe nicht beseitigt, sondern nur erschwert). 2. Wie sollen sie verstehen, was DEP, ASLR tun, wenn sie die Angriffe nicht verstehen, die diesen Schutz überhaupt notwendig gemacht haben? 3. Das Suchen nach Fehlern macht sie zu einem besseren Programmierer, da sie sich selbst und dem System weniger vertrauen. Achten Sie daher auf Verhaltensweisen, die nicht nur auftreten, wenn die Dinge richtig funktionieren, sondern auch, wenn sie schief gehen.
#4
+10
Steve
2011-03-01 11:11:43 UTC
view on stackexchange narkive permalink

Auf jeden Fall. Es sollte nicht ausreichen, dass sie wissen, dass dies Lösungen für das Problem sind, sie sollten wissen, wie und warum sie Lösungen für das Problem sind.

Außerdem unterstützen nicht alle Plattformen diese Technologien.

#5
+7
Jeremy Powell
2011-04-09 10:14:56 UTC
view on stackexchange narkive permalink

Hier gibt es bereits gute Antworten, daher werde ich nicht versuchen, sie erneut zu behandeln. Da es sich jedoch um Mechanismen handelt, die einen Pufferüberlauf verhindern, möchte ich etwas hervorheben, das Sie möglicherweise an Ihre Schüler weitergeben möchten:

Nur weil ein Programm in Java geschrieben ist, ist es nicht bedeutet, dass keine Pufferüberläufe vorliegen. Die Java Virtual Machine selbst ist nicht in Java implementiert. Es ist in (wahrscheinlich) C oder C ++ implementiert, die genauso anfällig für Pufferüberläufe sind wie jedes andere Programm.

Darüber hinaus gibt es viele Implementierungen der JVM. Für jeden, den Sie reparieren, gibt es zehn weitere, die wahrscheinlich immer noch anfällig sind.

Ich hoffe, ich bin nicht einfach über meine Seifenkiste gestolpert .... :-)

#6
+7
SunnyNewb
2012-07-06 16:15:49 UTC
view on stackexchange narkive permalink

Ich möchte aus der Sicht eines Schülers antworten, der kürzlich begonnen hat, sich eingehend mit Pufferüberlaufangriffen zu befassen. Auch ich hatte die gleichen Bedenken und Zweifel an den Vorteilen des Lernens über Pufferüberlaufangriffe, aber angesichts der Tatsache, wie viel ich gelernt habe, um zum Fleisch davon zu gelangen, bin ich sehr froh, dass ich mich dazu entschlossen habe.

Ich musste bisher:

  1. x86-Assembly lernen - hauptsächlich Ubuntu-basiert
  2. C-Programmierung lernen
  3. Werden Sie ein Ninja mit gdb
  4. Shell-Code verstehen
  5. Suchen Sie nach jedem IT-Sicherheitsforum, das ich möglicherweise kann, und lernen Sie, wie Software / Betriebssysteme sicherer werden.
  6. ol>

    Diese Fähigkeiten sind sehr gut übertragbar und ich bereue nichts. Leider habe ich niemanden, der mir das beibringt. Ich musste es mit Video-Tutorials und Beispielcodes für mein Master-Projekt ausarbeiten. Pufferüberlaufangriffe sind möglicherweise weniger ein Problem der IT-Sicherheit als vor 5 bis 10 Jahren, können jedoch definitiv als Sprungbrett dienen, um sich über komplexere oder zeitgemäßere Bedrohungen zu informieren.

#7
+3
pierce
2012-07-07 11:20:06 UTC
view on stackexchange narkive permalink

Nein, lernen Sie keine Pufferüberläufe. Lehren Sie Speicherbeschädigung. Lehren Sie Exploit-Primitive. Ja, sie müssen auch die Geschichte kennen, aber sie sollte nicht mehr als die Hälfte der Klasse einnehmen. Ich sage, wenn es um tatsächliche Hausaufgaben geht, geben Sie ihnen Herausforderungen, bei denen alle Speicherschutzfunktionen aktiviert sind, aber machen Sie den anfälligen Server möglicherweise schwächer, wobei einige Speicherangaben Hinweise auf verschiedene Offsets geben.

Sie sollten dies auch tun Verstehen Sie, dass viele Speicherschutzmaßnahmen meistens Spielereien sind und die "zufälligen Offsets" oft nicht so zufällig sind, wie Sie vielleicht denken. Sie sollten lernen, Fehler zu erkennen und die Fehler zu verwenden, die sie haben, um die Dinge zu untersuchen, die sie kennen, damit sie zu den gewünschten Dingen gelangen können.

Sie sollten eher daran denken, Funktionszeiger zu überschreiben als Rücksprungadressen und in bekannten ausführbaren Code (ret2libc, ROP) springen, anstatt in Shellcode auf dem Stapel / Heap zu springen.

#8
+1
Todd-ProNoob
2012-07-06 21:53:24 UTC
view on stackexchange narkive permalink

Als Student, der gerade eine C ++ - Klasse abgeschlossen hat, weiß ich, dass es nicht dasselbe ist. Aber mein Professor hat besonders darauf geachtet, über Pufferüberläufe zu unterrichten und wie man sie verhindert, und ich ermutige Sie wirklich dazu Unterrichten Sie in jedem Kurs, in dem Sie Programmieren unterrichten, weiter über Pufferüberläufe. Es kann ihnen nicht schaden, dies zu tun.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...