Forgot your password?
typodupeerror
Bug Java Oracle Security

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

Posted by samzenpus
from the long-road-coming dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by zero.kalvin (1231372) on Monday January 14, 2013 @01:46PM (#42583347)
    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..
  • by PenquinCoder (1431871) on Monday January 14, 2013 @02:04PM (#42583547) Homepage
    Java != Javascript
  • by Karlt1 (231423) on Monday January 14, 2013 @02:06PM (#42583561)

    "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.

  • by DragonWriter (970822) on Monday January 14, 2013 @02:16PM (#42583661)

    "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.)

  • by Anonymous Coward on Monday January 14, 2013 @02:22PM (#42583735)

    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.

  • by Todd Knarr (15451) on Monday January 14, 2013 @02:23PM (#42583747) Homepage

    Absolutely nothing. In fact, I think they've already found ways to break out of most of the hypervisors out there and gain access to the host machine from inside a VM. The only exceptions I can think of are the IBM mainframe hypervisors, and those have the dual advantages of a) decades of work finding and removing bugs and b) hardware that was designed to run the hypervisor and has special support for isolating the hypervisor from the virtual machines.

    Bear in mind that for cloud applications you actually need to be worried about the reverse: protecting your application from the hypervisor breaking into it. The worst incursions won't be from other applications breaking out of their VMs, it'll be incursions from the cloud provider's own internal network (from conventionally-infected machines) infiltrating the host machines' hypervisor software and from there reaching down to infect hosted applications.

  • by David_Hart (1184661) on Monday January 14, 2013 @02:24PM (#42583761)

    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).

  • by Billly Gates (198444) on Monday January 14, 2013 @02:38PM (#42583901) Journal

    I don't see think Java the platform is a security nightmare, but if someone doesn't need then don't install it, reduce your chances of being attacked with software you don use.

    Every Chrome/Firefox release has security vulnerabilities fixes, sometimes bugs as critical as this one, and I don't see people screaming "Remove Chrome, Disable Firefox...". All software has bugs, the problem with Java is the slow response of Oracle (and Sun at that time) fixing things, the update cycles are too long and only when a critical bug very loud on the media is found you see them pushing a fix.

    It is a security nightmare. You can put to geek stats and engineering and I will point to examples. At the end of the day what matters is how many exploits keep getting hit by it compared to other products. The only thing that comes close are IE 6 and flash. Even PDFs have exploits but not as many as java nor the frequency.

    Other browsers and technologies like silverlight have good engineering principles and less vulnerabilities. ... actually Firefox does have some as well compared to Chrome but htey update. Anyone uninstalling java yet uses Firefox 3.6 out of choice with +40 exploits is a fool. Chrome and IE 9 are sandboxed and so is silverlight. Java is sandboxed sort of, but it has RMI which sole purpose is to include untrusted unsigned c code. Corporations love it as it means +COM ojbect access for excel, but it also means a cracker can put whatever he wants in it. As Sun/Oracle try to sandbox and limit RMI it then breaks apps and teh corps end up whininng and locking down insecure old versions of it so their shitware apps work as they do with sticking with IE 6 as well.

    Java still has its uses but not as a browser plugin. Java 7 is truly aweful and I sitll use Java 6 on my computer with plugins disabled on my browsers. It also doesn't turn itself back on inside the browser either. Java 7 turned security off and it re-enables itselfs in the browser according to ther slashdotters.

    I highly advise anyone reading this to downgrade to Java 6 if they need it and then disable it in their browsers until all their apps no longer require it.

  • by Luckyo (1726890) on Monday January 14, 2013 @02:44PM (#42583965)

    Javascript has NOTHING to do with java.

  • by bbn (172659) <baldur.norddahl@gmail.com> on Monday January 14, 2013 @02:52PM (#42584053)

    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.

  • by bcrowell (177657) on Monday January 14, 2013 @03:23PM (#42584367) Homepage

    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.

  • by bbn (172659) <baldur.norddahl@gmail.com> on Monday January 14, 2013 @04:00PM (#42584743)

    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.

  • by Anonymous Coward on Monday January 14, 2013 @04:32PM (#42585057)

    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.

  • by aled (228417) on Monday January 14, 2013 @04:55PM (#42585333)

    Wrong answer!

    no, COBOL was written before software security was invented.

  • by dkf (304284) <donal.k.fellows@manchester.ac.uk> on Monday January 14, 2013 @06:42PM (#42586387) Homepage

    Java qualifies as a "bigger risk", and you mitigate it by uninstalling JRE.

    You mitigate by disabling Java in the browser. You also want to do that for performance reasons; the Java plugin is resource hungry by comparison with most other plugins (let alone with running Javascript code). I've been keeping it switched off for ages, and the logic behind that wasn't security even though that was one of the nice outcomes. Uninstalling the JRE is a much more extensive change, in that it tends to result in the inability to run any Java program, including many that are totally unrelated to web security. The best response is always the proportionate one.

    Of course, with this much hyperbole you're well suited to be a security commentator. Throwing babies out with bathwater a speciality! Next up, why you should disable HTTPS because of the compromise of one CA...

Repel them. Repel them. Induce them to relinquish the spheroid. - Indiana University fans' chant for their perennially bad football team

Working...