Security vulnerability in JRE
"A Vulnerability in JRE May Allow an Untrusted Applet to Escalate Privileges" (http://sunsolve.sun.com/search/document.do?assetkey=1-26-57221-1&searchclause=57221). "A vulnerability in the Java Runtime Environment (JRE) classloader can allow an untrusted applet to escalate privileges including reading and writing files and executing arbitrary code on client systems." You check, and see that on Windows you are using JRE 1.4.1. To be responsible, you install an updated JRE (such as 1.4.2_03).
You are also aware that you can have multiple versions of JRE installed (http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/version.html).
Can the malicious developer who is exploiting the vulnerability select JRE 1.4.1 and have his/her way with you, even though you have installed a JRE which is not vulnerable? Must you also uninstall the vulnerable JRE?
[889 byte] By [
notrump] at [2007-9-30 21:22:09]
The vulnerability is exposed only if one of the indicated versions is used to execute an applet. As long as the exploitable JRE doesn't run an applet, there is no possibility of the problem. If an applet is run on other than an indicated JRE, there is no problem.
Errr ... yes, but ... How would the exploitable JRE be selected?
You could foolishly aid the malicious person by selecting the exploitable JRE for them (in the Java Plug-in Control Panel Advanced tab, select "JRE 1.4.1 in C:\Program Files\Java\j2re1.4.1"). But if you leave that setting at "Use Java Plug-in Default" or "JRE 1.4.2_03 in C:\Program Files\Java\jre1.4.2_03", then is it possible for the malicious person to select the exploitable JRE?
Sure, if someone writes a program that can first make the necessary changes in the (Registry - or some where else?) to alter the default plug-in and gets you to download and install it (since applets can't do that, it'd have to be something else) then it's possible. But very unlikely; not something a reasonable person will worry about.
I had hoped I wouldn't need to work this out, but maybe I'll need to.
Referring back to the features of Muliti-Version support, http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/version.html, you can request that the browser use a specific Java Plug-In version by specifying a specific MIME type, such as
application/x-java-applet;jpi-version=1.4.1
If that succeeds, you are now free to use the flawed loadClass method of the sun.applet.AppletClassLoader from 1.4.1 and ... have your way with the upgraded, but still vulnerable, system.
Yes, it takes more than just an applet, but I don't believe it takes much more.
Thats a netscape tag. So even if it was possible you would be able to exploit less than 1% of the installed browser base. One would hope firefox doesn't support that tag but i haven't checked. I would also hope that the java plugin doesn't run versions that have known vunerabilities.....don't know how you could find out without installing all the software needed to replicate it.
I guess that's what I should expect, when I use an example from the developer guide. The developer guide focus on Windows and Netscape, but the concepts apply to Windows and IE, as well as Solaris and Linux.
That is, all platforms have multi-version support. I'm trying to figure out how easy it would be for a malicious web site to select a version with a security flaw. If a malicious web site can select JRE 1.4.1, then updating to 1.4.2_03 may not be sufficient protection against vulnerabilities in 1.4.1. You may also need to uninstall JRE 1.4.1.
But, gulp, here I go again ... If that explanation was sufficient, then please ignore the following example. I don't expect it to work. This Object tag would go in the body of an html file.
<OBJECT classid="clsid:CAFEEFAC-0014-0001-0000-ABCDEFFEDCBA" WIDTH = 790 HEIGHT = 478
NAME = "TestApplet" ALIGN = middle VSPACE = 0 HSPACE = 0
codebase="http://java.sun.com/products/plugin/1.4.1/jinstall-141-win32.cab#Version=1,4,1,0">
<PARAM NAME = CODE VALUE = "somethingfictional" >
<PARAM NAME = CODEBASE VALUE = "." >
<PARAM NAME = ARCHIVE VALUE = "market.jar" >
<PARAM NAME = NAME VALUE = "TestApplet" >
<PARAM NAME = "type" VALUE="application/x-java-applet;version=1.4.1">
<PARAM NAME = "scriptable" VALUE="false">
</OBJECT>
I suspect that the classid may be sufficient to select JRE 1.4.1.
great suggestions... I think that the most sensible thing to do is to try to write a applet that will do something inconsequential, but exploit the vulnerability (I can't seem to do it, as I keep on having service pack 2 not even let me run a "Hello World" applet withought yelling at
I don't like the idea of websites being able to specify different versions to run, no matter what OS it's on. I'm not convinced there is a major issue though, one of the tags you supplied works on netscape only and the codebase tag - sun doesn't have the older versions with exploits available for on the fly downloads.
To test, visit http://www.javatester.org/version.html
Get yourself a copy of JavaVersionDisplayApplet.class from this web site.
Get yourself a copy of the version.html file. Edit version.html, discarding all but the essential elements. Now add code to version.html that could specify a preferred JRE.
Be prepared to close all browser windows. That's why its nice to be able to do these tests locally.
The best I could do was hang IE. Big deal.
Almost a month later, and I have a convincing answer to my original question.
"Can the malicious developer who is exploiting the vulnerability select JRE 1.4.1 and have his/her way with you, even though you have installed a JRE which is not vulnerable? Must you also uninstall the vulnerable JRE?"
Yes, uninstall JRE 1.4.1.
To demonstrate this to yourself, use JavaVersionDisplayApplet.class from JavaTester.org (or a similar applet that can report version information) and make an HTML page consisting of:
<html>
<title>Java Version downgrade proof-of-concept</title>
<body>
Selecting Sun JRE 1.4.1:
<OBJECT classid="clsid:CAFEEFAC-0014-0001-0000-ABCDEFFEDCBA" width = "600" height = "100" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_1-windows-i586.cab##Version=1_4_1">
<PARAM NAME="code" VALUE="JavaVersionDisplayApplet.class">
</OBJECT>
The following example reports the Java Virtual Machine that would otherwise be in effect:
<applet alt="Browser has Java disabled" width="440" code="JavaVersionDisplayApplet.class">
</applet>
</body>
</html>
If JRE 1.4.1 is installed, the applet will run in that environment. No warning, just taking advantage of the available JRE. If JRE 1.4.1 is not installed, you will be asked if you want to install it.
For some reason, part of my applications can not be migrated to the JRE 1.4.2_06 or later, and I can not uninstall the old JREs.
Since the application doesn't use JRE plugin, I tried a work-around by changing the JRE plugin CLSID register on the window XP and pointing the CLSID to a secured version of JRE.
I also tried another work-around by renaming the NPJPI**_*.dll under jre/bin.
Both solutions seem working by the running the testing HTML mentioned above, and haven't found any side-effects on my applications so far. But I haven't got a chance to do a completed testing on the application.
Does anybody know any problems will be caused by doing those work-arounds?
Thanks
Are you sure it's indeed the 1.4.1 JRE being used or a 1.4.2 reporting itself as 1.4.1?
Well not 100%. But the clsid does point to the directory where I installed the jdk1.4.1.
