Security Expert Says Java Vulnerability Could Take Years To Fix, Despite Patch 320
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."
Java used to be secure and sandboxed (Score:5, Insightful)
What happened? Most of these exploits seem to rely on rewriting methods / accessing byte code ... how about disabling that access for applets as a temporary measure?
Re:Java used to be secure and sandboxed (Score:4, Insightful)
Nothing is truly secure, it's simply in a state where the vulnerabilities haven't been discovered yet.
Re:Java used to be secure and sandboxed (Score:5, Insightful)
No, no, no and no.
That is a terrible logical fallacy and everytime it comes up it gets to +5 insightful. This is simply just as broken as the "broken windows" fallacy (nothing to do with Microsoft Windows btw). And for whatever reason, even smart people fall for it.
The fallacy you're falling for is basically the "shades of gray" fallacy. Instead of having two choices (black or white) you argue that it's all gray. But hence you're restricting the issue to something even more simplistic than before: now instead of two colors, there's only one (gray, no matter the shade).
So instead of saying that there are technologies inherently more secure than others (for example OpenBSD hasn't been "rooted" nearly as many times as Windows XP), you're saying: "But OpenBSD had *two* remote-root bugs already found in 12 years and there are probably others, but we haven't found them yet. So it is impossible to create something secure".
And by doing you're implying that OpenBSD or Windows XP: it doesn't matter, it's all gray. Because nothing is truly secure.
And it's very sad. And it's a terrible fallacy to fall for.
Re:Java used to be secure and sandboxed (Score:5, Insightful)
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.
Re:Java used to be secure and sandboxed (Score:5, Informative)
Re:Java used to be secure and sandboxed (Score:5, Insightful)
They did not do nothing about it, they did release a patch. (That patch was insufficient and that is a valid point to criticize Oracle.)
Re:Java used to be secure and sandboxed (Score:4, Insightful)
Taking half a year to release the patch is also a valid point to criticize.
Re:Java used to be secure and sandboxed (Score:5, Insightful)
They did not do nothing about it, they did release a patch. (That patch was insufficient and that is a valid point to criticize Oracle.)
Taking half a year to release the patch is also a valid point to criticize.
The GP wasn't talking about the patch from Saturday.
There was a previous patch [slashdot.org] in October that partly plugged the hole that was exploited this time, and Oracle should definitely be bashed for that.
Re:Java used to be secure and sandboxed (Score:5, Funny)
This is absolutely not true. This vulnerability was a zero-day exploit. Zero-day means, by definition, nobody knew about it except the guys who wrote the exploit. We learned about this exploit last Thursday and had a fix on Sunday. Folks were up working around the clock to get the fix out.
We take security exploits incredibly seriously. Three times a year Oracle produces "critical patch updates" and we're working hard to clear out every bug from our backlog related to security, at the expense of new feature development. The suggestion that Oracle doesn't care about fixing these security problems is simply not true.
All you need to know about Oracle security (Score:3)
Three times a year.
Not when they are needed, or when they are wanted, or when they are actually ready... but rather, three times a year.
All you need to know about Oracle is contained in the parent post. They think "three times a year" is taking "security exploits incredibly seriously".
Reminds me of the sewer worker who's proud to take a bath every year, whether he needs it or not, because he's incredibly serious about hygiene.
Re: (Score:2, Informative)
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.
Re: (Score:3)
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.
This part of your post has wrong information. RMI is remote method invocation, has no relationship to execute c code. May be you are referring to JNI, Java Native Interface. I don't think you can execute native code in an unsigned applet. Why would anyone use it for accesing an excel spreedsheet is beyond me given that there are excelent pure java libraries for doing so.
Perhaps some company used Java and a COM bridge in the IE6 age when there where few alternatives and now is reticent to re implement it. Ma
Re: (Score:3)
The troll. You are feeding it.
It's a good one, better than most. Clever use of a series of real technical terms taken out of context and having nothing to do with the issue or Java or each other, and to finish it off, some truly awful advice
Re: (Score:3)
You do realize that many casual games are Flash, right?
FTFY
Re:Java used to be secure and sandboxed (Score:5, Insightful)
Maybe if they'd spent less time trying to get people to install ask toolbar or somesuch bullshit....
Re:Java used to be secure and sandboxed (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.
Re:Java used to be secure and sandboxed (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.
Re: (Score:2)
Java used to be secure and sandboxed. What happened?
That struck the odd chord in me too. In my mind Java has also held the status of being a relatively secure system.
Re: (Score:3)
Until it was the top attack vector in browsers for about 5 years running, sure. After that I think people started to go sour on it.
Re:Java used to be secure and sandboxed (Score:5, Insightful)
Re:Java used to be secure and sandboxed (Score:5, 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.
How do *you* propose interfacing to the OS? (Score:4, Interesting)
Of course there are hundreds or thousands of native API calls made by the Java stack.
Sooner or later you have to talk to the OS.
Re:How do *you* propose interfacing to the OS? (Score:5, 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.
Re: (Score:3)
Yes just google "java buffer overflow". There are tons of them. Here is an example: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Exploit%3AJava%2FCVE-2009-3869.M [microsoft.com]
The applet exploits a buffer overflow which existed in processing malformed images or audio files and affects Sun Java SE in JDK and JRE 5.0 before Update 22 and JDK and JRE 6 before Update 17. The applet exports Java class "vmain" with several member functions named "HB", "HexDecode", "mspray" and "paint". The member
Comment removed (Score:4, Insightful)
Comment removed (Score:5, Interesting)
Re:Two years? (Score:5, Insightful)
It looks like he randomly pulled a time frame. I cannot find an explanation for the two year estimate.
Ah, but that's the beauty of it! Owing to the blind hatred of Java around these parts, he can pull any alarmist timeframe out of his ass at any time, and we're certainly not going to argue with him!!! If anyone does, we can accuse them of liking Java, and then we excommunicate them and shame them in the entire software engineering world until they can't ever get a job again as a warning to others! It's brilliant!
Re: (Score:3, Insightful)
The hatred is by no means blind. And it isn't hatred so much as simple disgust.
Maybe it was a bad idea in the first place (Score:3)
Perhaps it's time to rethink the whole "execute in user space" thing and go back to HTML/CSS rendering and server-side CGI.
Near as I can tell, the whole user-space execution thing has been a security and compatibility clusterfark since day one. The "cloud" is a user data loss / privacy nightmare by design, too.
Honestly, it seems to me that outside of the usual HTML uses - reading a blog or a news site, shopping, that sort of thing - most people I know actually use the web to ship video and audio back and fo
Re: (Score:3)
Well I agree with you. I use the web to read stuff, sometimes to view stuff, and to post information back. I use applications for pretty much any other use of the web.
I don't need a lot of the "functionality" that seems to important to web developers these days. A lot of that stuff could be done on the back end, or at least with a much more secure system than relying on Javascript to implement it.
Its perhaps time for a new client-side coding mechanism that starts with security first and foremost, and adds e
Re:Two years? (Score:4, Insightful)
and we're certainly not going to argue with him
Why would we? Given that Java has been a security nightmare for 5+ years, 2 years to "secure" it (ie, doesnt have a critical exploit every 2 months) doesnt seem far fetched. If anything its conservative.
Seriously, anyone want to take bets on whether in 2 years browsers will still treat java plugin as an unusual security case? (firefox / chrome auto-disable java unless its the most current version due to its massive problems).
Re:Two years? (Score:5, Interesting)
Re: (Score:2)
Pretty poor assumption.
Re: (Score:3)
Hey, Java is going to be vulnerable for a couple years so that means you should hire us to help protect you.
Browser Plugins are Always Vulnerable (Score:5, Insightful)
The solution is to stop running untrusted code in your browser. If you are using a browser's default configuration, then any time you go to a website, the browser will automatically download and execute software from the website, in the form of Flash, Java applets, javascript, and Silverlight, if you have it installed.
And you think there aren't any vulnerabilities in any of those sandboxes?
Re:Browser Plugins are Always Vulnerable (Score:4, Funny)
But there are also well-documented CSS vulnerabilities [metasploit.com], XUL exploits [secunia.com] and even one in a JPG parser [verisigninc.com].
Should we disable those as well? Are you part of some guerrilla marketing campaign to bring back Lynx?
Re:Browser Plugins are Always Vulnerable (Score:5, Insightful)
Living is a risk. You have to quantify and try to mitigate the bigger risks.
Java qualifies as a "bigger risk", and you mitigate it by uninstalling JRE.
Re:Browser Plugins are Always Vulnerable (Score:4, Informative)
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...
Re: (Score:3)
It's not merely that Java represents a bigger risk. The reward is fairly insignificant as well.
If you disabled Flash, you'd have trouble with all sorts of sites, especially those that play video. If you disabled Java, you'd have trouble doing, well, nothing, because no respectable site has applets running straight off their pages anymore.
Re:Browser Plugins are Always Vulnerable (Score:4, Funny)
Personally I'd vote for bringing back gopher! And if that means we "lose" that blinged out "web-2.0" crap, it's not a day too soon.
Applies to all outside software (Score:5, Insightful)
That's not specific to Java, it applies to all software that's downloaded from an outside source and run on your local machine. That means Adobe Reader (PDF is simply a wrapper for a program written in Postscript), Flash (ditto, written in a special programming language) and even Javascript. It even includes downloaded TrueType fonts (the font hinting program they can include is just that, an executable program). Don't dismiss them just because they're sandboxed. Java was sandboxed, that didn't stop this vulnerability. Sandboxes are software and software has bugs in it, always. The only question is the number and severity of the bugs. The simpler the software, the fewer bugs there tend to be because there's fewer places for them to hide. Their favorite hiding place is in unexpected interactions between different parts of a piece of software, or between the software and the system it runs in, and simpler software has fewer and simpler interactions that're easier to get right.
This even applies to software you buy from a vendor. The difference is that with bought software you tend to download it only a few times and always directly from the source. Contrast this with the Web, where you're downloading multiple pieces of software on virtually every Web page you hit with no idea where they're coming from (and, in the case of advertising networks, the place you download them from may not even know who or where they're coming from).
Re:Applies to all outside software (Score:5, Insightful)
in short, 'mobile code' (stuff that runs and is sent across from them to you, to be run on YOUR platform) is untrustable by nature.
I never liked the idea of it, not once. I think its all a security fail.
'here, here's some binary code. run this. no, don't ask questions, just execute this, please'.
why people thought that was a good idea is beyond me.
Re:Applies to all outside software (Score:5, Informative)
Re:Applies to all outside software (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.
Server- vs. client-side Java (Score:5, Informative)
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.)
Re: (Score:2)
70% of pages do not use Java ? Make that 99.9999999999999% or something like that.
Re: (Score:2)
"70% of pages do not use Java ? Make that 99.9999999999999% or something like that."
I agree, I was refuting the original claim that "70% of web pages use Java"
Re: (Score:3)
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.
If this latest SNAFU gets developers to rethink using Java (or any similar tool), it may actually be a benefit to the web.
I haven't come across any website that uses Java in about three years (and even that one, was a very specialized website).
Name ONE popular website that requires Java.
Much hyperbole about nothing (Score:5, Interesting)
This guy isn't a security expert. He doesn't even know that Java is a programming language, and that Oracle's JVM is not "a version of Java used to surf the web". No self respecting expert would misuse terms the way he is, and he should be sued for doing it. It leads to ridiculous situations, where people think Java is inherently bad. I mean, isn't Android based on Java? OMFG ... don't get one of those! Haven't you heard. Java is vulnerable to attack! If the writer got what this guy said correct then his guy is either shilling for Apple or Microsoft against Google/Android, hates Oracle, or is phenomenally incompetent.
Re: (Score:2, Insightful)
You think the chief security officer of Rapid7 doesn't understand the nature of Java, huh? It's not that he's trying to use language that most people would understand, but that he actually does not know that Java is a programming language and what the JVM actually is. That's some stunning logic you've got there. He sounds like he probably knows his stuff [rapid7.com].
Re: (Score:3)
Re: (Score:2)
This guy isn't a security expert. He doesn't even know that Java is a programming language, and that Oracle's JVM is not "a version of Java used to surf the web".
You're assuming quite a lot there. I didn't see any sentence in there that said "Oracle's JVM is the version of Java used to surf the web." But most of the exploits we're talking about certainly do involve the version of Java used to surf the web -- the Java plugin. People who are just running desktop Java apps aren't vulnerable. These are browser exploits, or exploits that attack the interface between the plugin and the browser. If a Reuters reporter wants to simplify the language so that regular people c
Re: (Score:2)
It's not a version of Java! Java is a fscking programming language. It is no more correct to say Java is vulnerable than is is to say C is vulnerable or COBOL is vulnerable. Also ...
Oh ... Oh ... I remember this one from elementary school English class! It would be because he used quo
Re: (Score:2)
The Android OS uses Linux as its kernel, so I'd say they have something in common. Once again, Java is a programming language, which Android uses, and in fact the whole user space is, as I already stated, based on it, so I'd say they have something in common there. Fin
Re: (Score:2)
Re: (Score:2)
Sandboxes are software and software has bugs in it, always.
So how does this bode for the cloud? OSs and hypervisors are conceptually similar at least to an OS and a sandboxed app. What prevents a hypervisor from being attacked in the same way that Java's sandbox was?
Re:Applies to all outside software (Score:4, Informative)
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.
Re:Applies to all outside software (Score:5, 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.
So? (Score:4, Interesting)
Running programs from untrusted sources has always been unadvisable. I run java every day, and I'm not worried at all about getting compromised. Apps like ImageJ or UGENE, if they weren't written in Java would be written in a native language which would be just as dangerous to install. So don't be an idiot and run programs from random websites and you'll be fine.
It's the browser plugin... (Score:5, Insightful)
Running programs from untrusted sources has always been unadvisable. I run java every day, and I'm not worried at all about getting compromised. Apps like ImageJ or UGENE, if they weren't written in Java would be written in a native language which would be just as dangerous to install. So don't be an idiot and run programs from random websites and you'll be fine.
The problem is, the default Java runtime install includes a browser plugin that allows Java applets embedded in a webpage to run automatically. Code delivered this way is supposed to run inside a strict sandbox, but that sandbox has been repeatedly shown to be full of holes.
(Desktop apps written in Java, including UGENE and ImageJ [and Eclipse, and the mostly-not-Java LibreOffice] do not use the browser plugin and will run fine even if the browser plugin is disabled or deleted completely. Your standard don't-be-an-idiot advice does indeed apply to these kinds of apps. But the JRE you installed to run ImageJ will install the browser plugin you never asked for and don't need.)
Oracle really should consider making the browser plugin a separate, optional, non-default installation.
Re: (Score:2)
I would trust them about as much as anyone can trust any third party software. My point is that the software is written in java is as irrelevant as if it were written in C++.
Re: (Score:2)
That is an outdated security fallacy before ads had flash and java in them.
Why are you running java in ads? Don't do that, and the problem goes away. You wouldn't run .exe files from an ad would you?
Re: (Score:3)
That's what NoScript is for. Doesn't just stop Java, but javascript, flash, etc.
Fact free claims (Score:2, Insightful)
HD Moore, chief security officer with Rapid7, a company that helps businesses identify critical security vulnerabilities in their networks, said it could take two years for Oracle to fix all the security bugs that have currently been identified in the version of Java that is used for surfing the Web.
How is Mr. Moore computing this interval? Nothing is offered in these stories about why it would take Oracle "two years" to "fix" the "security bugs".
Re: (Score:3, Funny)
So a rewrite? (Score:3)
It didn't take two years to write JDK in the first place...
Re: (Score:2)
Re: (Score:2)
the JDK has been around for at least a decade
You're trying to slam someone else for their dubious selection of jargon but the best you could do is "at least a decade"? (For nostalgia purposes I keep the original edition of "Java in a Nutshell" on my desk, copyright 1996, and yes, JDK is in the index.)
Re: (Score:2)
Re: (Score:2)
And for what it's worth, the JDK includes the JRE and JVM, so yes, if the original JDK took a year (it didn't Oak [wikipedia.org] was under development for three years and it took two more for Java 1.0 to ship.) a complete rewrite, including the JVM should be less than two.
The problem with that statement is not that he said JDK, it's that his understanding of the time frame and effort to produce the original JDK is completely wrong and furthermore the current JVM looks almost nothing like the original from 1995. A complete
Re: (Score:2)
Applies to all (Score:2)
This also applies to every desktop OS - ESPECIALLY Windows. How many years has Microsoft been attempting to secure Windows? Obviously if you care about national security, you will unplug your PC today.
OpenJDK (Score:2, Interesting)
Are those security flaws also affecting OpenJDK 6 and/or 7?
Applets? (Score:3)
Why exactly do we need applets on joe smoe's machine? If your a corporation enable it.
It would be great if all browser had a whitelist of domains that you tag a site for any of this stuff. Yes youtube can play flash, other sites not. Advertisers will just use animated gif\javascript or whatever.
Sure there is this plugin and that to accomplish this...time for FF, Chrome, and IE to build this stuff in and make it off by default and super simple to address. Of course you've got grandma on IE 6/7/8, but even then MS could put out a patch that just turns off applets. The next time IE starts up it ask the user. Group policy would override.
Re: (Score:3)
Re: (Score:2)
Flashblock [mozilla.org]?
Re: (Score:2)
both firefox and chrome ask per site if you want to run java.
by the way.. just today I had to fix my java plugins to work, to authenticate via my bank to a 3rd party(the bank uses a java applet for security code input.. there's no real logic why though). the shit wouldn't work in either firefox or chrome before I ran it in IE. such bullshit.
Why isn't there a whitelist-only mode? (Score:5, Interesting)
I find it strange that I can install a flash blocker that allows me to whitelist certain websites but that similar functionality seems to be missing for Java... the easy answer is to not allow java to run unless the site or even specific URL is in a whitelist.
The java engine should check whether the code it is about to execute is from a whitelisted location before it executes it. If the code is not, it should warn the user, perhaps prompting to add the site.
That way your banking and ecommerce sites would still work easily while the "bad guys" would at least have to successfully social-engineer you into adding their site, a situation much better than what we currently see where all you have to do is inadvertently browse to a web page with compromized java applets embedded.
Re:Why isn't there a whitelist-only mode? (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).
Re: (Score:3)
like chrome & firefox? they both ask per site...
Could somebody explain.... (Score:3)
That, to me, seems so obvious as a basic security measure, it amazes me that software as old as Java would still have such vulnerabilities.
I can see absolutely no reason to start with an unprivileged app that can somehow give itself privilege it did not start with. In reality, such actions should be up to the user to decide *before* they run the app (although that may still be quite vulnerable to social engineering, it would at least remove the technical aspects of the vulnerability).
Re: (Score:3)
Signed applets can access the hard drive. I don't know how they thought it's a good idea.
Applets are vulnerable, not Java (Score:3)
This is like opening an email attachment form the same domain name; don't do that because somehow that PDF file, Excel file, Word document or whatever is harboring some evil code.
But does any of that mean you should remove Excel or PDF readers or Word or Libre Office or anything else from your own machine? Of course not. Java apps are totally safe on your machine and removing Java from your machine makes exactly zero sense.
The only people (mis) representing this situation are people who have an economic stake in "competing " languages and runtimes and language warriors , so that would include M$, consultants who want to be able to bill to rewrite Java apps (for no reason) , authors and evangelists from competing languages etc etc etc . You should all be ashamed of yourselves. C# is a great language , Java is a great language , Perl is a great language , C is a great language, Scala is a great language, Lisp is a great language.. so just GTFU.
One could say that about any piece of software (Score:2)
They all have undiscovered holes. What makes Java any riskier than IE? What makes it any riskier than Chrome or Firefox? Is it the lack of any update strategy on Oracle's part?
Do you guys realize... (Score:2)
same flaw in C# (Score:2)
Doesn't this mean the same problem is present in C#, as it is really just a clone of Java
Reflection API (Score:3, Interesting)
However, I admit that this is also a good thing to hopefully encourage Oracle to provider quicker updates/patches/etc.
I still don't see a mass migration to other languages happening. JAXB (and annotations in general) is one of the best things Java ever invented. I have yet to find a language with features that make XML reading/writing as easy as JAXB. Unicode, i18n, and l10n were well-done from the beginning. Even though people laugh at the notion of byte code and the cross-platformness of Java, I still have yet to see another language do this better. Java will die when either a better solution emerges or enough corporate shill kills it.
And I still don't understand why Linux is being bogged down with C# mono programs such as Banshee, TomBoy, etc. Don't get me wrong, these are great programs, but why not write them in a language that is more open? It would have been just as easy to do these in Java with GTK+.
oracle as damage, route around it (Score:5, Insightful)
To paraphrase a well known saying, I think it's time for the internet to start seeing oracle as damage and route around it.
One really simple thing that seems needed, and that should be extremely simple to do, would be a whitelist/blacklist plugin for java applets in firefox. The vast majority of java applet users are probably people who work in a bank, a law practice, or a medical office and only ever need to use a single applet. They need an option where they can blacklist all java applets by default, but allow applets from medicalrecords.com or whatever. These folks can't just disable the java plugin completely. Setting plugins.click_to_play to true is also a solution, but it breaks sites that use flash, and it doesn't protect the business against an office worker who clicks on stuff without thinking. (I tried setting this flag on my desktop box at home, and was too much of a nuisance. This is what I have flashblock for, and flashblock does the job better.)
Another helpful step would be to make it easier for people to find out which versions of java they have on their computers and easier for them to avoid unsafe versions. On my ubuntu box, managing this is a total mess. If I do "java -version", it tells me I'm running java 1.6, which would be immune to this vulnerability. But if I check inside the directory /usr/lib/jvm , it turns out I actually have 1.5, 1.6, and 1.7 all installed. Well, which one is firefox using? I get zero results from dpkg --get-selections icedtea . In firefox, doing tools:add-ons:plugins tells me I have IcedTea-Web 1.2, which tells me nothing about the java version. Typing about:plugins in the url bar shows me literally two dozen version numbers. Googling turns up somebody's test app at http://javatester.org/version.html [javatester.org] , but (a) how do I know this guy isn't a black hat, and (b) even if that showed I was currently running 1.6, what happens if a future apt-get upgrade bumps me into 1.7?
The final thing that should really happen IMO is that the OSS community should get off the java upgrade treadmill. The IcedTea [wikipedia.org] project should designate some version such as 1.6 as a high-security, stable version and focus some real effort on making that version secure. Distros should stop packaging 1.7+ until the dust settles -- and if that take a couple of years, who the heck cares? Hell, I wouldn't care if it took a decade, or forever.
Re:So long/The way the future was (Score:5, Funny)
This might seriously impede the Year of Java on the Desktop
Re: (Score:3)
Re: (Score:2)
"It's been in MY jar of molasses since 199x!"
Re:So long/The way the future was (Score:5, Funny)
Re: (Score:3, Funny)
Re: (Score:2)
Does COBOL have as many security issues as Java?
Re:So long/The way the future was (Score:5, Funny)
Re: (Score:3, Informative)
Wrong answer!
no, COBOL was written before software security was invented.
Re:WTF is the deal with Java and being so insecure (Score:4, Insightful)
The idea is that you are at the same time providing a full language and a sandbox. Together. Java is not inherently more or less secure than any other language (well, mostly), but the above premise is extremely hard to pull off correctly. Think of an applet as some piece of code you download and execute. Would you trust doing that in any special language? Think of Flash, how many flash issues have we seen? And Flash is "less complex" than Java.
Re:WTF is the deal with Java and being so insecure (Score:5, Informative)
Javascript has NOTHING to do with java.
Re: (Score:2)
Yes, but Java is a completely different language from JavaScript.
Re: (Score:3)
You know, that's the funny thing I've always found about trying to do accurate software estimates. Because programming is so predominantly a thinking-heavy activity, the time that you're spending trying to figure out how long something is going to take can almost as easily be spent actually doing it.
I've always found it frustrating to try to explain this to people who want estimates on how complex certain tasks are, when you don't actually have enough data on those tasks yet to know, and by the time yo