DEP und Paketfilter

[(del)]

DEP ist gestorben
http://www.heise.de/security/meldung/Neue-Exploittechnik-trickst-Speicherschutz-aus-958806.html

Die meisten (?) Packetfilter aka "Firewalls" lassen sich austunneln
http://www.heise.de/security/meldung/Exploit-Code-mit-DNS-Tunnel-958342.html

[Gnafoo]

DEP ist nach wie vor sinnvoll, weil es schlicht gegen den klassischen Buffer Overflow hilft, der vergleichsweise einfach auszunutzen ist. Zwar lässt es sich mit ROP umgehen, allerdings ist der Exploit deutlich schwieriger und ich würde vermuten, dass es mit ASLR und idealerweise einem 64-Bit-System nur noch sehr schwierig (wenn überhaupt) umzusetzen ist.

Der DNS-Tunnel ist zwar ganz interessant, erscheint mir aber nicht allzu kritisch, da es nur um den Datenaustausch geht, wenn der Schadcode bereits auf dem Rechner ist (zumindest verstehe ich es so). Und da gibt es so oder so auch noch andere Möglichkeiten (schließlich lässt die Firewall immer irgendwelche Nutzdaten durch).

[(del)]

Warum idealerweise 64bit? Was läuft diesbezüglich unter 64bit anders?

[Gnafoo]

Der Adressraum ist größer und damit hat ASLR mehr Spielraum für die zufällige Platzierung der einzelnen Segmente.

[(del)]

Ah so :smile: Ok. Danke.

[(del)]

Ah ja. Hab das mal wieder ganz vergessen.

DEP ist nach wie vor sinnvoll, weil es schlicht gegen den klassischen Buffer Overflow hilft, der vergleichsweise einfach auszunutzen ist. Zwar lässt es sich mit ROP umgehen, allerdings ist der Exploit deutlich schwieriger und ich würde vermuten, dass es mit ASLR und idealerweise einem 64-Bit-System nur noch sehr schwierig (wenn überhaupt) umzusetzen ist.Einspruch? =) Alter Hut vom März 2009.

"Dieser Nils, der seinen richtigen Namen nicht nennen wollte, sorgte auch für ein weiteres Highlight, indem er Microsofts neues Rennomierstück, Internet Explorer 8 auf Windows 7, knackte – trotz Data Execution Prevention, Adress Space Layout Randomisation und so weiter."

http://www.heise.de/security/meldung/Pwn2own-Wettbewerb-Safari-IE8-und-Firefox-gehackt-207855.html

[Gnafoo]

Naja gut prinzipiell sind ASLR und DEP ja auch nur ein zusätzliche Hindernisse und müssen ohnehin nur im Notfall greifen, wenn die Software tatsächlich eine Lücke hat. Das muss man sich dabei einfach vor Augen halten. Wirklich sicher geht es nur, wenn die Software selbst keine Angriffsfläche bietet. Die üblichen automatisierten Exploits sind aber durch DEP/ASLR vermutlich erheblich schwieriger geworden. Damit ist auf jeden Fall schon einmal einiges gewonnen.

Der Heise-Artikel ist ja leider relativ knapp, wenn es um die technischen Details geht, aber Google verrät, dass es offensichtlich der .NET/Spraying-Exploit aus [1] (ab Seite 33) war. Im Grunde genommen schreibt man dabei den Shellcode in einen möglichst großen Speicher-Bereich und versucht einen Sprung "ungefähr in diesen Bereich" zu provozieren (alles afair, so gut kenne ich mich da auch nicht aus). Ist natürlich ungemein praktisch, dass man dafür externe DLLs in den Explorer reinladen konnte, die man mit dem Shellcode vollschreiben kann. Validierung und Sandbox umgeht der Exploit sowieso über die Lücke. Inzwischen hat Microsoft das wohl auch geändert.

Was man aber auch bedenken sollte: der Browser ist meist ein 32-Bit-Prozess (selbst auf einem 64-Bit-System, da war ich vorhin ungenau), dadurch ist das Spraying noch praktikabel. Bei 64 Bit hängt es ein wenig davon ab, wie frei die Segmente vom Betriebssystem wirklich platziert werden können.

Im Übrigen sagt "Nils" selbst, dass solche Exploits relativ schwierig geworden sind [2]:
I came here with that vulnerability. It’s another nice bug but it was really, really difficult to write the exploit because of those ASLR and DEP. I had to use some techniques around those mitigations and make a lot of preparation to make it a reliable exploit. It was very, very hard.


Soll heißen: gestorben sind DEP und ASLR nicht. Sie sind sicher mit entsprechendem Aufwand umgehbar, aber das liegt in der Natur der Sache. Das ist eine letzte Lösung, wenn die Software einen Fehler enthält und verhindert die meisten automatischen Exploits (Computerwürmer etc.). Gegen manuelle Angriffe ist in der Situation sowieso schwer vorzugehen. Aber immerhin machen DEP und ASLR diese deutlich schwieriger.

[1] http://taossa.com/archive/bh08sotirovdowd.pdf
[2] http://blogs.zdnet.com/security/?p=2951

[Nightspider]

Und wie wird nun das Wetter im Sommert? :/

Ich wette 50% der Leute klicken den Thread an, in der Hoffnung das es ein Bomben-Sommer wird.

[Pinoccio]

Der DNS-Tunnel ist zwar ganz interessant, erscheint mir aber nicht allzu kritisch, da es nur um den Datenaustausch geht, wenn der Schadcode bereits auf dem Rechner ist (zumindest verstehe ich es so).Wenn ich das tichtig verstehe, dann kann man so auch Paywalls bei HotSpots umgehen. Für Mailabruf oder so könnte es reichen.
Der Aufwand ist natürlich ziemlich hoch.

mfg

[(del)]

Es gab schon reichlich zu sehen :)

Nicht nur beim iPhone alle SMSe saugen und Safari auf OSX knacken. Diesjahr ist unter Win7 nicht nur Firefox gefallen, sondern auch die IE8-"Sandbox" :| auf Win7. ASLR und DEP, kein Problem.
http://www.heise.de/newsticker/meldung/Pwn2own-iPhone-gehackt-Internet-Explorer-8-Firefox-und-Safari-auch-963348.html

[Coda]

Der Adressraum ist größer und damit hat ASLR mehr Spielraum für die zufällige Platzierung der einzelnen Segmente.
*Sehr* viel mehr sogar. Heap Spraying ist bei 64-Bit nahezu aussichtslos.

Nicht nur beim iPhone alle SMSe saugen und Safari auf OSX knacken. Diesjahr ist unter Win7 nicht nur Firefox gefallen, sondern auch die IE8-"Sandbox" :| auf Win7. ASLR und DEP, kein Problem.
Die Sandbox wurde wohl nicht gebrochen. Er konnte den Exploit also nur in dem sehr eingeschränkten Prozess-Context laufen lassen.

[(del)]

Die Sandbox wurde wohl nicht gebrochen.Scheint zu stimmen.