There is a serious vulnerability in Java that leaves users running any of the current versions of Windows open to simple Web-based attacks that could lead to a complete compromise of the affected system. Two separate researchers released information on the vulnerability on Friday, saying that it has been present in Java for years.

The problem lies in the Java Web Start framework, a technology that Sun Microsystems developed to enable the simplified deployment of Java applications. In essence, the JavaWS technology fails to validate parameters passed to it from the command line, and attackers can control those parameters using specific HTML tags on a Web page, researcher Ruben Santamarta said in an advisory posted Friday morning.

Tavis Ormandy posted an advisory about the same bug to the Full Disclosure mailing list on Friday as well. Ormandy said in his advisory that disabling the Java plugin is not enough to prevent exploitation, because the vulnerable component is installed separately.

In short, if you have a recent version of Java running on a Windows machine, you’re affected by this flaw.

“Java.exe and javaw.exe support an undocumented-hidden command-line
parameter “-XXaltjvm” and curiosly also “-J-XXaltjvm” (see -J switch in
javaws.exe). This instructs Java to load an alternative JavaVM library
(jvm.dll or libjvm.so) from the desired path. Game over. We can set
-XXaltjvm=IPevil , in this way javaw.exe will load our evil jvm.dll.
Bye bye ASLR, DEP…,” Santamarta said in his advisory.

Because the JavaWS technology is included in the Java Runtime Environment, which is used by all of the major browsers, the vulnerability affects all of these applications, including Firefox, Internet Explorer and Chrome, on all versions of Windows from 2000 through Windows 7, Santamarta said. Browsers running on Apple’s Mac OS X are not vulnerable.

In his advisory, Ormandy said that he notified Sun about the vulnerability but that the vendor didn’t believe it was serious enough to warrant an emergency patch.

“The toolkit provides only minimal validation of the URL parameter, allowing us to pass arbitrary parameters to the javaws utility, which provides enough functionality via command line arguments to allow this error to be exploited. The simplicity with which this error can be discovered has convinced me that releasing this document is in the best interest of everyone except the vendor,” Ormandy said.

The workaround for this problem is to disable JavaWS and Javaws.exe, Santamarta said in his advisory. Ormandy has set up a proof-of-concept URL, included in his advisory, that demonstrates the exploit.

Julien Tinnes has more information about this class of Java vulnerability.

Categories: Vulnerabilities

Comments (26)

  1. Shawn G
    2

    I’m not sure I see this as a huge problem.  You would have to have a compromised machine reachable through SMB.  At least in the US the major ISPs all block SMB over their network.  The only place this could be a problem is a large business, and still you would have to have a host machine which is trusted by the machines you want to infect on their LAN. 

    I just don’t see this being a big problem.

  2. Rob Leland
    4

    I agree this sees a minor exploit. The only way besides the shared LAN, would be if the alternate JVM could be downloaded by a URL then there would be an issue.

  3. Anonymous
    5

    You simply load the jvm from the browser cache folder, where you have previously visited the poisoned JVM.  That is the same reason why IE is paranoid about running pages from the local disk, giving them lower rating than the wide interenet!

  4. Fry
    6

    I think you missed the point of Julien’s post. There are *multiple* Java flaws and there are more to come. And yes, Windows, Linux and MacOS X are all vulnerable.

  5. Anonymous
    7

    I don’t get it?

    Webstart can run native dlls by design, why would a hacker go to all the trouble of building an evil JVM when they can just go straight for the jugular?

  6. DLMeyer
    8

    Fry, it doesn’t require much more typing to be much more precise. Windows is not vulnerable. Nor is Linux. Nor OS X. It would seem that browsers running on systems with those OSs are vulnerable, but this is not attacking the OS itself.

    If I understood this correctly.

     

  7. Anonymous
    9

     DLMeyer: running arbitrary dll’s is no more secure than running with an axe, Eugene

  8. Cesar Figueiredo
    11

    It is hard to believe Sun Microsystems (now Oracle’s) would ignore Java flaws and let one of its most important products become unreliable. If the flaws are real and the company has apparently underestimated them (maybe for not publicly admitting Java has vulnerabilities), it is probably taking care of such flaws and is going to release a fixed new version as soon as viable.

  9. win
    12

    > “…and let one of its most important products become unreliable…”

    JAVA and reliability? :O

  10. PrescottTX
    13

    Nice pink floyd reference, and yes you are tight – it is not the OS that is affected but the browser running the java on an  OS.

  11. Anonymous
    14

    As others have said, you have to get the poisoned vm onto the machine as a file in the file system in order to laod it.  Which means you’ve already broken the security and might as well go straight after windows with a hacked system lib.

    This, as usual, is sensationalist nonsense.

     

  12. xilvar
    15

    The ‘major isps’ do not block SMB over their networks. I in fact have NEVER had a dsl or cable connection which could not connect to an available smb connection on a public ip. Inbound SMB is partially blocked by the simple fact that most consumers are behind a NATing router thus no packets are routed inwards except for connections already established outwards.

    However this does absolutely nothing to block smb originating from inside the NAT router reaching outwards to a public IP. That is all this exploit needs.

  13. Anonymous
    17

    I don’t think Ormandy and Santamarta are talking of exactly the same vulnerability. Ormandy’s proof of concept doesn’t seem to rely on using an “evil JVM”, but rather in executing a jar file with malware inside.

    From what I can see, Ormandy’s vulnerability is far more dangerous than Santamarta’s.

  14. Anonymous
    18

    Plz, also consider the fact, that you don’t need the SMB/CIFS protocol. Windows does have builtin support for WebDAV. Even if this support is very bad implemented, there are ways to get a drive mounted over HTTP, which routes fine throught NAT devices ;-)

  15. Anonymous
    19

    Bad thing is that Ormandy’s vulnerability is already being exploited!

    My laptop was attacked last Friday using seemingly the same scenario, that is, some online ad apparently contained a script. The script launched webstart, and webstart downloaded and launched without any prompt a piece of malware, which pretended to be an antivirus software and tried to con me into buying a ‘full’ version. It took me a full evening to eradicate it and make sure no hidden nasty bits were left in the system.

    Be warned!

  16. Anonymous
    20

    Help I have a Javaw.exe and every program I run it says “Javaw didn’t detect anything in internetal ways” and now I can’t get it to stop. Please help I do not need a virus anymore.

  17. Anonymous
    21

    Question… So what am I supposed to do exactly to prevent this from happening? And if this happens what do I do? Should I just delete or uninstall all Java? Please respond and thanks for your time.

  18. daniel
    22

    The main naysayers are saying “but the exploit requires running a DLL in the target’s filesystem so the machine is already compromised.”

    1. The path to the browser’s temporary cache value and can be called using a system object that is available to the whole machine

    2. A poisoned site can download a file into the cache. This is one way malware propogates.

    3. Once downloaded, even into a temporary file, it’s game over.

    4. Clearing the cache regularly won’t help; if I were doing this one of my first actions would be to copy my evil.dll to another location accessible to the browser and run it from there.

    5. Linux is vulnerable. The vulnerability is less than that of Windows due to how the filesystem and it’s security are structured, but it’s still vulnerable. Same goes Mac OS.

    6. As stated, the JavaWS is needed and not all machines have that. A little social engineering on a poison site can quite easily induce a user to download  and install it straight from Sun’s own website (which can fool even astute users).

    This not a trivial exploit that can be ignored. Stop fooling yourselves.

    I am a security researcher for a major datacenter; as such I am a white hat. A good white hat frequently wears a gray one to understand the competition.

  19. FIXNICHOLS
    24

    saying that this is not a serious security issue is like putting your head in the sand, when incorporated into a more sophisticated self propagating piece of malware, this will just be one more spread vector.  I agree with The Author.

  20. Jimmy B
    26

    Info from Secunia

    ——————-
    Mitigation
    ———————–

    If you believe your users may be affected, you should consider applying one of
    the workarounds described below as a matter of urgency.

    - Internet Explorer users can be protected by temporarily setting the killbit on CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA. To the best of my knowledge, the deployment toolkit is not in widespread usage and is unlikely to impact end users.

    - Mozilla Firefox and other NPAPI based browser users can be protected using File System ACLs to prevent access to npdeploytk.dll. These ACLs can also be managed via GPO.

    Detailed documentation on killbits is provided by Microsoft here

    http://support.microsoft.com/kb/240797

    Domain administrators can deploy killbits and File System ACLs using GPOs, for more information on Group Policy, see Microsoft’s Group Policy site, here

    http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx

    You may be tempted to kill the HKLM…JNLPFileShellOpenCommand key, but
    the author does not believe this is sufficient, as the plugin also provides enough functionality to install and downgrade JRE installations without prompting (seriously). However, if none of your affected users are local
    Administrators, this solution may work (untested).

    As always, if you do not require this feature, consider permanently disabling it in order to reduce attack surface.

Comments are closed.