Neue Exploittechnik trickst Speicherschutz aus

Ein Sicherheitsexperte hat die ersten bösartigen PDF-Dateien entdeckt, die die Speicherschutzfunktion Data Execution Prevention (DEP) durch Return Oriented Programming umgehen.

In Pocket speichern vorlesen Druckansicht 280 Kommentare lesen
Lesezeit: 3 Min.

Ein Hacker mit dem Pseudonym Jduck hat die ersten bösartigen PDF-Dateien entdeckt, die die Speicherschutzfunktion Data Execution Prevention (DEP) durch eine recht neue Technik namens Return Oriented Programming umgehen. Damit sind die Tage gezählt, an denen DEP noch wirklich Schutz bieten kann, noch bevor es sich allgemein durchgesetzt hat.

Jduck wollte den PDF-Exploit eigentlich nur in seine Schwachstellentest-Plattform Metasploit einbauen. Dabei fiel ihm auf, dass er trotz des beim Adobe Reader 9.3 standardmäßig aktiven DEP reibungslos funktionierte. Bei der folgenden Untersuchung des Exploits stellte er fest, dass der eine Liste von Speicheradressen enthielt, die jeweils auf den hinteren Teil von Funktionen zeigten – also auf ein paar Maschinenbefehle gefolgt von einem Return. Das ist charakteristisch für eine recht raffinierte, neue Exploit-Technik, die bislang nicht in freier Wildbahn gesichtet wurde.

Typischerweise funktioniert ein Exploit so, dass man eigenen Code als Nutzdaten einschleust und durch Speichermanipulationen veranlasst, dass das Programm diesen anspringt. Als Schutzmaßnahme setzen moderne Systeme die Zugriffsrechte für Datenspeicherbereiche so, dass dieser zwar gelesen, aber nicht ausgeführt werden kann; bei Windows heißt das Data Execution Prevention (DEP).

Die klassische Technik, DEP zu umgehen, nennt sich Return-to-libc. Sie erfordert keinen eigenen Code, sondern nutzt die bereits geladenen Systemfunktionen, etwa zum Starten eines Programms. Dazu muss man nur den Stack passend präparieren, damit etwa ein Return-Aufruf im Programm die Exec-Funktion anspringt und diese dann die passenden Parameter auf dem Stack vorfindet, damit sie etwa notepad.exe ausführt.

Unter anderem Hovav Shacham präsentierte 2007 eine verallgemeinerte Version dieses Konzepts, bei der man sich seinen Exploit-Code aus bereits im Speicher vorhandenen Code-Fragmenten zusammenstellt, die jeweils direkt vor einem Return-Befehl stehen. In seinem lesenswerten Papier erklärt er, dass diese Programmiertechnik etwa im Kontext der Libc Turing-komplett sei – man damit also beliebige Programme realisieren könnte. Prinzipiell kann das Zusammensuchen der benötigten Code-Fragmente sogar ein spezieller ROP-Compiler übernehmen. 2009 demonstrierten Forscher, dass sich damit selbst Wahlmaschinen mit konsequenter Harvard-Architektur hacken ließen; auf der diesjährigen RSA-Konferenz hielt Dino Dai Zovi einen Vortrag zu "Practical Return Oriented Programming".

Bislang konnte man davon ausgehen, dass die Mehrzahl von bösartigen Dateien, die versuchen, Sicherheitslücken in Programmen auszunutzen, um Schadsoftware zu installieren, durch DEP abgeblockt werden. Dass diese neue Exploittechnik jetzt in Malware-Files auftaucht, lässt Böses ahnen. Es steht zu befürchten, dass die Schutzwirkung von DEP verfliegt, noch bevor es sich auf breiter Front durchgesetzt hat. Denn erst bei den 64-Bit-Systemen, die bei der Intel-Architektur das No-Execute-Bit einführten, ist DEP standardmäßig für alle Programme aktiv; auf den immer noch weit verbreiteten 32-Bit-Systemen darf jedes Programm selbst entscheiden, ob es mit DEP läuft oder ohne. Dazu gehören auch 32-Bit-Windows-Versionen auf 64-Bit-Hardware.

Siehe dazu auch

(ju)