Slashdot Mirror


A Tidal Wave of Java Flaw Exploitation

tsu doh nimh writes "Microsoft warned today that it is witnessing a huge spike in the exploitation of Java vulnerabilities on the Windows platform, and that attacks on Java security holes now far outpace the exploitation of Adobe PDF bugs. The Microsoft announcement cites research by blogger Brian Krebs, who has been warning for several months that Java vulnerabilities are showing up as the top moneymakers for those peddling commercial crimeware exploitation kits, such as Eleonore, Crimepack and SEO Sploit Pack." Several days ago, Oracle released a patch that fixed 29 Java security flaws.

14 of 238 comments (clear)

  1. Re:How? by adisakp · · Score: 5, Informative

    CVE Attacks Computers Description

    CVE-2008-5353 3,560,669 1,196,480 A deserialization issue in vulnerable versions of JRE (Java Runtime Environment) allows remote code execution through Java-enabled browsers on multiple platforms, such as Microsoft Windows, Linux, and Apple Mac OS X.

    CVE-2009-3867 2,638,311 1,119,191 Another remote code execution, multi-platform issue caused by improper parsing of long file:// URL arguments.

    CVE-2010-0094 213,502 173,123 Another deserialization issue, very similar to CVE-2008-5353.

  2. Re:How? by Florian+Weimer · · Score: 5, Informative

    Propagation generally happens via applets, loaded through IFRAMEs or Javascript-based redirects. Actual payloads are not yet OS-agnostic (even though the exploits themselves are).

  3. Re:How? by adisakp · · Score: 4, Informative

    The keywords in the above descriptions are "remote code execution through Java-enabled browsers on multiple platforms". The flaw is not Windows specific but could also be exploited on OSX and Linux.

  4. Re:How? by hydrofix · · Score: 3, Informative

    I feel that NoScript is doing a greater and greater work in protecting me each and every day.

  5. Re:How? by doishmere · · Score: 3, Informative

    A few days ago smbc comics was hit with a Java exploit in the form of a popup that installed a trojan on users machines. People affected were discussing it here; from this it looks like mostly Windows machines were infected, but at least one user claims Ubuntu was affected.

  6. Re:How? by Bill_the_Engineer · · Score: 4, Informative

    CVE-2008-5353 was fixed with Apple's Java Patch #2 on June 15, 2009.

    CVE-2009-3867 was fixed with Apples Java for OS X 10.6 Update #1 and Java on 10.5 Patch #6 on December 3, 2009

    CVE-2010-0094 was fixed With Apple's Java for OS X 10.6 Update #2 and Java on OS X 10.5 Update #7 on May 18, 2010

    The flaw may not be Windows specific, but OS X is not included in your list.

    --
    These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  7. Re:How? by Bill_the_Engineer · · Score: 5, Informative

    After further research. It appears that Oracle/Sun latest version of Java addressed these issues for the Windows and Linux platforms. This looks like a case of people not updating their Java JRE.

    --
    These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  8. Re:Patch bloat by TubeSteak · · Score: 4, Informative

    What's annoying is there is no real "patch" as such. You have to install the entire 77mb package from scratch and it installs crap like the yahoo toolbar by default.

    If you update through the java control panel, it definitely does not grab the entire 77MB package + toolbar.

    --
    [Fuck Beta]
    o0t!
  9. Re:Patches have been available for a long time by ADRA · · Score: 4, Informative

    There are maybe 3 major versions of Java still in somewhat standard use: 1.4, 1.5, and 1.6. Unless the application in question has some very specific quirks, users should always be able to use the latest and greatest version of 1.6 to run them. The allowance for using older versions of the platform is a feature, not a hindrance.

    It means that if I want to use "BadSoftwareCompany"'s piece of java software, I'm not confined with downloading and breaking my host's latest version of the java if their code only works with 1.4 or 1.5. If I didn't have the feature, I just couldn't use the software without a huge head-ache. To assume that every version of every software will work forever is delusional, but at least there are facilities to support the older tech.

    --
    Bye!
  10. Re:How? by init100 · · Score: 3, Informative

    NoScript blocks all executable content on a web page, including Java applets, Javascript, Flash, etc, and lets you decide which ones to allow on a per-site basis.

  11. Re:Nice try by turgid · · Score: 3, Informative

    Incidentally, what are some of my fellow Slashdotters' checklists when they experience an infection? I haven't had any problems for years, so I haven't put much thought into it until last week when I got infected.

    Me neither. I switched to Linux in 1996.

  12. Re:Patches have been available for a long time by lgw · · Score: 3, Informative

    All it needs is to allow me to manage a list of repositories that I trust (one centrally managed repository won't fly in the commercial world, but it doesn't have to be that way). It's a small addition - maybe next year will be the year of Windows on the desktop!

    --
    Socialism: a lie told by totalitarians and believed by fools.
  13. Re:How? by broken_chaos · · Score: 4, Informative

    It sandboxes Java and Flash until we tell them to run, too.

    You're saying two different things in this sentence, only one of which is true. NoScript does only load plugins if you click on them (assuming it's configured to do so), but it does not "sandbox" plugins in any way. If you allow a malicious object to be loaded in a plugin (such as by clicking on it), NoScript does nothing to stop it.

  14. Re:Java applets require authorization by SamiKoivu · · Score: 3, Informative

    CVE-2010-0094 is a privilege escalation vulnerability in the JVM. The applet does not need to be signed and the user does not need to click OK on any dialog window. Even though the flaw is in an RMI related class, the exploitation does not require RMI privileges. No RMI stuff actually takes place, it just happens that this class is a trusted JVM core class that could in the previous versions of Java be exploited into elevating untrusted applet code privileges, thusly escaping the sandbox. Having escaped the sandbox the Java code can then do whatever it wishes, within the local privileges of the user running the browser process, including native code of the platform it's being run on.