Java-0-Day unter der Lupe

Bei einer ersten Analyse des bereits öffentlich verfügbaren Exploit-Codes fällt auf, dass er so gar nicht auffällt: Der Angriffscode sieht auf den ersten Blick aus, wie jedes andere Java-Programm – von exotischem Bytecode ist keine Spur. Sein Geheimnis ist laut Michael Schierl, der selbst bereits mehrere Java-Lücken aufgedeckt hat, dass er etwas tut, was er eigentlich gar nicht dürfte: Er schaltet den SecurityManager einfach ab und bricht damit praktisch aus der Sandbox von Java aus.

Eigentlich sollte der eingeschränkte Code eines unsignierten Applets keinen Zugriff auf die Klassen der sun.*-Hierarchie erhalten, da diese nur zur internen Verwendung freigegeben sind. So stellt die Klasse sun.awt.SunToolkit unter anderem eine Methode getField() bereit, durch die man auf private Attribute von anderen Klassen zugreifen kann. Der Exploit verschafft sich diesen Zugriff über eine Lücke im ClassFinder und umgeht dann einen weiteren Sicherheitscheck, um via getField() das Attribut "acc" eines Objekts auszutauschen. In dem Attribut ist eigentlich vermerkt, dass das Objekt etwa von einer Klasse aus dem Applet http://angriff.boese-seite.tld/exploit.jar stammt und daher vom System abgeschottet innerhalb der Sandbox laufen sollte.

Der Exploit erstellt zunächst ein Statement-Objekt, das die Methode System.setSecurityManager(null) aufruft und die Sandbox damit effektiv abschaltet. Dann baut er in Handarbeit ein AccessControlContext-Objekt auf, das eine Klasse repräsentiert, die von der lokalen Festplatte gestartet wurde und somit alle Rechte hat. Dieses Objekt speichert der Angriffscode anschließend über den Zugriff auf das "acc"-Attribut im setSecurityManager-Statement. Da für Java damit der Eindruck entsteht, dass das Statement von vertrauenswürdigem Code abstammt, wird es danach klaglos ausgeführt.

public void disableSecurity()
	throws Throwable
{
 Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]);
 Permissions localPermissions = new Permissions();
 localPermissions.add(new AllPermission());
 ProtectionDomain localProtectionDomain = new ProtectionDomain(
   new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions);
 AccessControlContext localAccessControlContext = 
   new AccessControlContext(new ProtectionDomain[] {localProtectionDomain});
 SetField(Statement.class, "acc", localStatement, localAccessControlContext);
 localStatement.execute();
}

Anschließend kann der Exploit auf dem System schalten und walten, wie er möchte. Der analysierte Exploit startet zu Demonstrationszwecken den Windows-Taschenrechner calc.exe über dieselbe Methode, die auch eine legitime Java-Anwendung nutzen würde. Prinzipiell hätte der Angreifer hier auch ein Statement bauen können, das Dateien auf der Festplatte löscht oder eine nativen Payload nachlädt und ausführt. Ein bereits im Internet gesichteter bösartiger Exploit infiziert PCs mit dem Remote Administration Toolkit Poison Ivy.

"Intrusion Detection Systeme (IDS) und Antivirensoftware wird es schwer haben, generische Signaturen für die Lücke bereitzustellen, weil kein exotischer Bytecode benötigt wird, um sie auszunutzen – im Gegensatz zu den letzten beiden großen Lücken", befürchtet Schierl. Von der Schwachstelle sind alle Betriebssysteme betroffen. Theoretisch könnte ein Virenschreiber Malware programmieren, die über diese Lücke Windows, Mac OS X und Linux infiziert. Hierzu muss er nur einige wenige betriebssystem-spezifische Anpassungen vornehmen. Ähnliche Fälle gab es bereits; der Flashback-Trojaner infizierte über unsichere Java-Installationen hunderttausende Macs.

Oracle hat sich bislang nicht offiziell zu der kritischen Schwachstelle geäußert. Bei Erscheinen dieses Artikels hat das Unternehmen noch die Java-Version 7 Update 6 zum Download angeboten, die – genauso wie alle älteren 7er Versionen – auf die hier beschriebene Weise angreifbar ist. Wer eine anfällige Version auf seinem System installiert hat, tut gut daran, die Browser-Plug-ins für Java-Unterstützung zu deaktivieren. Andernfalls ist es nur eine Frage der Zeit, bis sich ungebetene Malware-Gäste auf dem Rechner einnisten.

Update, 28.8., 21:40: Die Beschreibung der Funktionsweise des Exploits präzisiert und neue Erkenntnisse aus der umfangreichen Analyse von Immunity eingebaut. (rei)