Question about Java exploits

Discussion in 'malware problems & news' started by dlimanov, Nov 4, 2010.

Thread Status:
Not open for further replies.
  1. dlimanov

    dlimanov Registered Member

    Joined:
    Jun 10, 2009
    Posts:
    204
    I can't seem to get a consistent answer on this, including from Java support: if you upgrade to the newest version of Java (1.6.0.22 now) but do not uninstall older vulnerable version, can malware explicitly reference older vulnerable Java version and therefore exploit it?
    Does anyone know this for sure? Any references or examples to the contrary?
    Thanks!
     
  2. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    JavaRa can remove traces of old Java versions.
     
  3. Cudni

    Cudni Global Moderator

    Joined:
    May 24, 2009
    Posts:
    6,956
    Location:
    Somethingshire
  4. dlimanov

    dlimanov Registered Member

    Joined:
    Jun 10, 2009
    Posts:
    204
    Thanks for replies! Cudni: I wasn't able to find any direct references of exploit invoking an older, vulnerable version of Java on a machine where latest version is present. Do you have a quote or direct link to the post I may have missed?
    Thanks!
     
  5. ABee

    ABee Registered Member

    Joined:
    Jun 2, 2010
    Posts:
    330
    ~ Off Topic Remarks Removed ~

    You have two or more fully functioning versions of a software installed on your machine.
    What is it that would make you think malware, or anything/anyone else, would only be able to access the most recent version?
     
    Last edited by a moderator: Nov 4, 2010
  6. dlimanov

    dlimanov Registered Member

    Joined:
    Jun 10, 2009
    Posts:
    204
    That's what I'm trying to prove. I've had a build 21 of Java installed, which I upgraded to 22, the latest. Java applet in control panel showed that both User and System version of Java is correctly updated to 22 and even though I could manually search for older versions (I never uninstalled build 21 via Add/Remove Programs), I could not have added it manually as an active second User version in there.
    Testing exploits targeting build 21 all failed also; build 22 would load, as it should, being default Java processing engine on the system. So unless I get my hands on a specially-crafted exploit that references older, inactive version of Java on my machine, all this is pure speculation.
     
  7. ABee

    ABee Registered Member

    Joined:
    Jun 2, 2010
    Posts:
    330
    I'm assuming when you installed build 22, the installer uninstalled build 21. Sun-Java has recently gotten a lot better at doing that, and not leaving multiple versions on the machine.
    So all of your pointers are for build 22 to open when called, as it should be.

    Why would a regular user intentionally seek out and install an older build after installing the newest, more secure build?
    Perhaps an entirely different version of the JRE, like 1.4, but why a different build of the same version?

    Yet given your scenario of two builds of the same version on the machine, with all registry and program settings pointers pointing towards the latest build, then I suppose a malware would first need to access those settings and make a change so that the older, vulnerable build is called when the JRE is told to open.
    That means the malware would also first need a different access point to the machine than the older, vulnerable version of the JRE. And if malware has worked it's way onto the machine without using the JRE, then it doesn't need to bother changing any JRE settings to get itself onto the machine.

    So perhaps it's very unlikely that with the latest version on a clean machine, malware is going to be able to remotely invoke the older version to be called.

    On the other hand, in the real world of computing, the danger from not upgrading to the latest, most secure version is that the older, vulnerable version is still the default version that does get called remotely when the JRE is told to open.

    Besides, it's just good practice to make sure any older builds are uninstalled after upgrading to the newest build, if only to take your scenario out of the equation altogether.

    Some apps might need an entirely different version in order to function, like for example 1.4, but anything that needs JRE 1.6 is going to be able to use the latest build of that version.
    So it seems that with the JRE installer now removing previous builds when it installs the latest one, there would be no realistic point in the user seeking out and reinstalling an older build of the same version, making your scenario somewhat of a moot point.

    Perhaps I misunderstand you, or don't see all the ramifications, or perhaps your question is one of pure academics or hypothetics.
     
Loading...
Thread Status:
Not open for further replies.