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.

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?

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 ++).

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.

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 .... :-)

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.
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.

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.

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.