FYI, www.java.com is still dishing out 1.4.2_05 Phil
---- Phil Randal Network Engineer Herefordshire Council Hereford, UK > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jouko Pynnonen > Sent: 23 November 2004 01:40 > To: [EMAIL PROTECTED] > Subject: [Full-Disclosure] Sun Java Plugin arbitrary package > access vulnerability > > > > OVERVIEW > ======== > > Sun Microsystem's Java Plugin connects the Java technology to > web browsers and allows the use of Java Applets. Java Plugin > technology is available for numerous platforms and supports > major web browsers. > > A vulnerability in Java Plugin allows an attacker to create > an Applet which can disable Java's security restrictions and > break out of the Java sandbox. The attack can be launched > when a victim views a web page created by the attacker. > Further user interaction is not required as Java Applets are > normally loaded and started automatically. > > Such Applet can then take any action which the user could: > browse, read, or modify files, upload more programs to the > victim system and run them, or send out data from the system. > Java is a cross-platform language so the same exploit could > run on various OS'es and architectures. > > > > DETAILS > ======= > > There is a number of private Java packages in the Java VM, > meant to be used only by the VM internally. Java Applets > can't normally access these packages because of security > concerns. Attempting to access them normally results in an > AccessControlException. > > The problem is that JavaScript code can bypass the access > control by using so called reflection API. The following > piece of example JavaScript acquires a reference to a > supposedly restricted, private class "sun.text.Utility": > > [script language=javascript] > var c=document.applets[0].getClass().forName('sun.text.Utility'); > alert('got Class object: '+c) > [/script] > > This isn't possible by a normal Java Applet, and shouldn't be > for JavaScript either. The JavaScript code could now > instantiate the class or pass it to an Applet that could use it. > > An attacker can't do much with the utility class in this > example, but could use other private classes to exploit the > vulnerability. Some of them allow e.g. direct access to > memory or methods for modifying private fields of Java > objects. The latter allows an attacker to simply turn off the > Java security manager, after which there is no sandbox > restricting what the Applet can do. > > > > VULNERABLE VERSIONS > =================== > > The Java Plugin versions 1.4.2_04 and 1.4.2_05 were tested on > Windows and Linux. Web browsers tested were Microsoft > Internet Explorer, Mozilla Firefox and Opera. It should be > noted that Opera uses a different way of connecting > JavaScript and Java which caused the test exploit not to work > on Opera. However the problem itself (access to private > packages) was demonstrated on Opera too, so it may be > vulnerable to a variation of the exploit. > > > > SOLUTION > ======== > > Sun Microsystems was informed on April 29, 2004 and has fixed > the problem in J2SE 1.4.2_06, available at > > http://java.sun.com/j2se/1.4.2/download.html > > > > CREDITS > ======= > > The vulnerability was discovered and researched by Jouko > Pynnonen, Finland. > > > > -- > Jouko Pynn�nen Web: http://iki.fi/jouko/ > [EMAIL PROTECTED] > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
