5 ms·

Well, Java sucked, Apple blocked it. If you pretend your technology to be secure, but constantly fail in that aspect, you'd expect this kind of result.

• cma 14y ago
  It also seems like a big failure of the OS/browser that it can't be sandboxed effectively.
  • btian 14y ago
    The point of Java is that it has access to things at system level. If you don't need that, use HTML.
    • cma 14y ago
      That is the point of trusted java applets that you opt in to, but not to standard applets that do something like animate a scientific model. Java handles sandboxing, but there is no reason the OS couldn't provide a backup. When something wants to run with elevated permissions you would get a prompt from Java, and then a prompt from the OS/browser. If Java had an exploit bypassing its own prompt, the OS and/or/in-conjunction-with browser would still prompt as soon as it tried to do something that required elevated permissions. Chrome does its own back-up sandboxing for Flash, even though Flash is supposed to do it itself, but Chrome lets other plugins slide (because Chrome doesn't have a notion or interface for user-controlled elevated permissions in its sandbox): http://productforums.google.com/forum/#!topic/chrome/err6mfbFqTs http://productforums.google.com/forum/#!topic/chrome/err6mfb... This is the failure I'm referring to. It is a concious decision and not an unintentional mistake, but it is still full of fail. Chrome used to have a --safe-plugins option that is mentioned in the linked thread and could have attempted to prevent something like this exploit and still allowed something like a Java-animated lava lamp or whatever.
  • dakimov 14y ago
    Well, Java in its very core idea is supposed to be safe in the first place, because of the restrictive programming model that leads also to problems in efficiency. And if the entire idea of abstraction and safety does not work, what's the point of Java overall? I'd better use C++ then.
    • MichaelGG 14y ago
      What's being exploited is an insecure API. Can you explain how this is different than finding a bug in a browser's JS implementation, or finding a kernel bug that lets you perform local escalation of privilege?
      • dakimov 14y ago
        It's simple. Java inventors/developers once said: this new language is entirely safe because it runs on a virtual machine and prohibits any insecure operations, maybe a bit slow, but now we will finally get rid of all the buffer overruns and similar security breaches that we were so used to with the good old C/C++. It's safe now! And here we go again, exploits are routinely found in what used to be the totally safe and isolated environment. C/C++ can be safe and reliable as well, except infrequent bugs and exploits — you cannot absolutely get rid of bugs, because what involves the humans will never be solved at 100%. But in this case Java and native code appear the same from the security perspective: exploits are found here and there. What's the point of Java then entirely? What does it give except slowdown, memory consumption and restrictions? Personally I believe the only proper way to implement security isolation is with hardware support. Native/sandboxed/virtual machine — does not matter, It is proven now by Java's fail.
  • revscat 14y ago
    Did you notice the part where this affects every OS and browser? This is a flaw in Java, not any operating system or browser. Java, across all platforms, provides a way to execute native code if you have the correct permissions to do so. A way was found to exploit this by getting access to a raw classloader using MBeans. Once you have access to that classloader you can do whatever you want. Please do not try and turn this into an OS war.
    • cma 14y ago
      I wasn't making this an OS war, as I didn't recommend any alternative OS/browser. See my later comment, since I wasn't very detailed in the initial one.