Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apple Nabs Java Exploit That Bypassed Disabled Plugin

Posted by timothy on from the heading-them-off-before-they-head-you-off dept.

Trailrunner7 writes "Apple on Thursday released a large batch of security fixes for its OS X operating system, one of which patches a flaw that allowed Java Web Start applications to run even when users had Java disabled in the browser. There have been a slew of serious vulnerabilities in Java disclosed in the last few months, and security experts have been recommending that users disable Java in their various browsers as a protection mechanism. However, it appears that measure wasn't quite enough to protect users of some versions of OS X."

8 of 97 comments (clear)

  1. Java and flash... by sdsucks · · Score: 4, Insightful

    Incredibly, still the biggest shit on the internet.

    Too bad, as a language I actually like Java. Flash is crap though, always was, always will be.

    1. Re:Java and flash... by eksith · · Score: 5, Interesting

      The problem with flash are the developers. ActionScript can do a lot of things... that doesn't mean those things should have been done. Of course if sandboxing was foolproof, things would have worked better for both technologies. Hopefully HTML5 can fill the gap for both and we can finally do away with both plugins.

      --
      If computers were people, I'd be a misanthrope.
    2. Re:Java and flash... by casab1anca · · Score: 5, Informative

      Flash is crap though, always was, always will be.

      Flash may be crap now but for a long time, it (and Shockwave before it) was the only practical way of displaying interactive multimedia content in the browser.

    3. Re:Java and flash... by GoodNewsJimDotCom · · Score: 4, Interesting

      Windows could have been sandboxed too making it impossible to edit system files, access files outside the installation directory too. Also autobooting at start should be something only the user can choose and can't be automatically checked. This would have rendered most viruses useless. This should have been done circa 1995-98 when the Internet was just going mainstream.

      --
      God spoke to me
    4. Re:Java and flash... by JDG1980 · · Score: 4, Insightful

      Windows could have been sandboxed too making it impossible to edit system files, access files outside the installation directory too. Also autobooting at start should be something only the user can choose and can't be automatically checked. This would have rendered most viruses useless. This should have been done circa 1995-98 when the Internet was just going mainstream.

      The problem is that circa 1995-98, the average home PC simply wasn't powerful enough to handle this kind of sandboxing while maintaining acceptable performance. Windows 9x basically ran on bare metal (one bad app could easily bring the whole system down) and there was no such thing as security. It was crude, but it was the best you could do on a Pentium 100 with 8 megs of RAM (16 if you were lucky). A modern smartphone leaves these old systems in the dust. The Windows NT series has a Unix-style security model, though it was undermined by the need for backwards compatibility forcing regular users to run as administrator (UAC was a belated attempt to fix this). But this also means that NT needs a faster processor and a lot more RAM than 9x. The first home version of Windows based on the NT kernel was XP, and people were all up in arms about its "outrageous" system requirements back in 2001.

      Nowadays, you can usually get away with running as a limited user and escalating only when installing or updating a program from a trusted source. I agree that sandboxing could be more sophisticated than it is on Windows, but this isn't a unique flaw; in fact, it's a result of copying the outdated Unix security model, which assumes that the program is the user and would do roughly what the user wanted (maybe true in the 1970s on shared university systems, but obvious nonsense now).

    5. Re:Java and flash... by drinkypoo · · Score: 3, Interesting

      E.g. you can changeroot the process and then it can't do anything.

      chroot is a big help, but it doesn't preclude gaining access to memory, and if you have enough access to that then you can write files using other processes' permissions. You really need to virtualize to even claim to have a sandbox which is useful from a security standpoint. Even then it's not impossible to exploit a virtual driver and gain access to the underlying hardware indirectly.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  2. Not a bug? by subanark · · Score: 5, Informative

    A webstart link is simply a jnlp file, which is an xml file, that if opened with javaws will start up the Java application (in a sandbox or warn the user it won't). This does not attach to the web browser and runs in its own frame. When you install Java it should associate jnlp files with javaws so that when you click with a browser it shouldn't launch the javaws program unless you choose to always open with it when you click it.

    From the article this seems to be a bug with the way the Mac handled scripts in an unexpected way.

    1. Re:Not a bug? by _xeno_ · · Score: 3, Interesting

      It's only not a bug in that it was by design.

      Basically Mac OS X has a list of "safe" files that don't bring up an "are you sure you want to open this file?" dialog after it's been downloaded. The idea is that if you download a text file, you won't get a dialog warning you that the file is insecure when you try and open it.

      JNLP files were put in that list, presumably based on the assumption that Java was "secure." (Bad assumption!)

      The fix was to remove them from the safe list, so now you'll get an "are you sure?" dialog from the OS itself rather than assuming Java is secure.

      --
      You are in a maze of twisty little relative jumps, all alike.