Slashdot Mirror


Security Expert Says Java Vulnerability Could Take Years To Fix, Despite Patch

An anonymous reader writes "After the Department of Homeland Security's US-CERT warned users to disable Java to stop hackers from taking control of users' machines, Oracle issued an emergency patch on Sunday. However, HD Moore, chief security officer of Rapid7, said it could take two years for Oracle to fix all the security flaws in the version of Java used to surf the web; that timeframe doesn't count any additional Java exploits discovered in the future. 'The safest thing to do at this point is just assume that Java is always going to be vulnerable,' Moore said."

11 of 320 comments (clear)

  1. Re:Java used to be secure and sandboxed by zero.kalvin · · Score: 5, Informative

    Yes, but when a bug is found in either of them (Firefox or Chrome) devs race to plug the whole. On the other hand Oracle knew about this since August and did nothing about it..

  2. Re:Applies to all outside software by PenquinCoder · · Score: 5, Informative

    Java != Javascript

  3. Re:Applies to all outside software by Karlt1 · · Score: 5, Informative

    "Trying to use 'todays' internet with Java disabled is not a viable option. A realistic estimate is that over 70% of all common websites require Java to function correctly.

    It is unfortunate that so many web developers use Java in places where it just isn't required. While I agree that Java Script does provide needed functionality in some situations, that is not the case in many (most) applications."

    Really? This day and age someone not knowing the difference between Java and Javascript?

    70% of pages do not use Java. Javascript yes but they are completely different.

  4. Server- vs. client-side Java by DragonWriter · · Score: 5, Informative

    "Trying to use 'todays' internet with Java disabled is not a viable option. A realistic estimate is that over 70% of all common websites require Java to function correctly.

    The only way that number is within an order of magnitude of being correct is if it is a reference server-side Java, which isn't the issue. In-browser Java is the issue, and very few common websites require in-browser Java to function correctly (in-browser JavaScript, perhaps, but aside from artifacts of early-90s marketing in the naming, the two have nothing in common.)

  5. Re:Java used to be secure and sandboxed by Anonymous Coward · · Score: 5, Informative

    yes, we already blacklist Java across the company where I work due to this.

    in general they're quite liberal about letting employees manage their own computers (it's a software dev studio) but Java is blacklisted because of the Ask bundling, which is considered Spyware at corporate level and difficult to remove cleanly.

  6. Re:Why isn't there a whitelist-only mode? by David_Hart · · Score: 5, Informative

    If you are using Firefox, Chrome, or Safari, you can install NoScript. I find that it works well. It takes some effort to figure out which scripts you need to run for each page to display properly and which are the advertisement scripts. But it does the job. So far, I have found only one site that doesn't work with NoScript, but it's not a common site.

    If you are not using If you are using Firefox, Chrome, or Safari, then it may be time to switch. I, personally, have always preferred IE. However, I made the switch to Firefox a couple of years ago and haven't turned back since. The security plugins for FireFox are much better than for IE and most are free (open source).

  7. Re:WTF is the deal with Java and being so insecure by Luckyo · · Score: 4, Informative

    Javascript has NOTHING to do with java.

  8. Re:Java used to be secure and sandboxed by bbn · · Score: 4, Informative

    Java code is sandboxed but many parts of the Java standard library is not written in Java. Every time SUN took the easy way out and used an external library instead of reimplementing in Java, they opened the platform to exploits of bugs in that library. Also it seems the SUN engineers did not really like to code in Java so they made a very large part of the platform in C - even when they could have made those parts in Java.

    The standard library rt.jar file has more than 1000 methods that are implemented by native calls to C code or third party C libraries. It is simply too much to check that every single one of those crossed all the t's and dotted the i's. So we keep finding more bugs.

    The sandbox itself is fairly secure so there is nothing wrong with the idea. It is just the implementation that went wrong.

  9. Re:Applies to all outside software by bcrowell · · Score: 4, Informative

    PDF is simply a wrapper for a program written in Postscript

    Not true. Postscript is a Turing-complete language. PDF is basically a redesign of postscript that, among other changes, makes it into a Turing-incomplete language. This makes PDF inherently more secure than Postscript.

    The security flaws that keep popping up in Adobe Reader are not holes in PDF itself, they're holes in other features that were added on later, such as the ability of recent versions of PDF to embed javascript. By default, AR will execute javascript that's embedded in pdf files. This is both a privacy (people can track readers) and a security issue (more than one stack overflow bug has been discovered that's related to js). To disable js, go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript".

    Better yet, simply don't use AR as your PDF plugin in your browser. On linux, Evince is pretty good.

    The situation with PDF is actually closely analogous to the one with java applets. Both technologies were designed with security in mind, and are inherently possible to implement straightforwardly in a secure way. Both are open specs that are freely implementable without paying patent royalties. In both cases, the evolution of the spec is currently being guided by an evil corporation that doesn't care about security. The main difference is that in the case of PDF, the relevant read/write functionality exists in multiple completely independent implementations, whereas for java, there is no full reimplementation by anyone besides sun/oracle, only implementations that use almost all of oracle's code and replace portions that weren't freely available.

  10. Re:How do *you* propose interfacing to the OS? by bbn · · Score: 4, Informative

    Yes the point is that you can make it "later" instead of "sooner". Example of this is the Google Native Client which exposes OS services through only an API consisting of a handful of allowed methods compared to the thousands of the Java platform. It is a lot easier to make 10 methods secure than 1000.

    Native Client can run C code inside the Sandbox, so you can still take advantage of existing libraries.

  11. Re:Java used to be secure and sandboxed by Anonymous Coward · · Score: 4, Informative

    If you download from java.sun.com (or http://www.oracle.com/technetwork/java/index.html) then there's no bundled toolbar. Only the installers from java.com have the bundled toolbar.