World would be such a better place if we could get rid entirely of Flash and Java for the web.
It's not only the exploits, the fact that they are so frequent also means users got to update both Java and Flash almost every single day, which is a terrible user experience.
Flash still seems more popular for webgame development. I've run across a handful of HTML5 games, but many more Flash games. Not entirely sure why. Libraries, maybe? Is there something comparable to Flixel for HTML5?
99% of all Webbased gaming is flash. Why? Because HTML5 is about at a point where flash was 5 years ago. Thats not just my opionion but facts (see all game portals, FB game etc.) and what the big guys say (http://www.wooga.com/press/releases/wooga-html5-project-goes...)
I've had good experiences so far by keeping a dedicated browser for use with "legacy" services (such as school) that require Java. I haven't tried it, but I would suspect the profile manager in Firefox may help with that kind of setup, too.
First, it would be significantly more of a hassle to boot up a separate OS for the purpose of executing a short-lived task (such a submitting homework, or doing banking, as others have mentioned). Related to that, there is a slight disconnect between the host filesystem and the guest filesystem. The more convenience one has (e.g. greater transparency and sharing) the greater the risk.
Related, but separate from that: how would you know the VM was compromised and thus should be destroyed? One could presumably just periodically destroy (or revert to snapshot). Perhaps even if it was compromised, maybe the short lifespan of the VM would limit the damage to others.
Is it actually a JVM exploit, though? From FireEye's blog it sounds more like a library exploit which allows unconstrained clearing of memory, which then leads to a JVM escape because it blows away the JVM state. I wouldn't class that as a JVM exploit.
But the point still stands that this specific exploit is NOT a JVM exploit? Is it an actual exploit of the JVM implementation, or just the libraries?
The problem has always been that Sun shipped way too big a runtime for Java applets - the entire Java SE - when they should have made a third class ("edition") for browsers. That's a huge attack surface, and that's were most of the exploits have been, including this one, unless someone knows otherwise.
To be honest they inherited all these applets (and applets-only) security exploits from Sun. Sun are the ones to blame here.
Actually the ones to blame are the uber f^^^tards who thought that Java applets was a technology worth anything.
One should go back in time and read Usenet's comp.lang.java.programmer from back in the early Java days. There were two camps: the retards who thought applets were a good idea and going to revolutionize the Web and the enlighted ones who pointed out that it was all wasted energy on a piece of shitty technology that would only create problems.
I was in that latter camp and, honestly, it feels good to see that no-one is disputing anymore that Java applets were really one of the most f^^^tarded piece of technology ever invented.
So, speaking as one of those fucktards[1], the idea that two third parties could possibly create interactive content without the participation of a standards body in the middle was a pretty neat idea. The 'pure render view' which was most commonly espoused early in the debate had the challenge that going from idea, to something people could use, took 6 months at a minimum and a year typically.
Since you were there you no doubt experienced the amazingly slow progress of <table></table> support in HTML as it got pushed out to the #1 source of browsers (AOL) on a very slow timeline. The period between 1993 (can't use tables in your web pages because no one except XMosaic users have them) to early 1995 where "most" but certainly not a preponderance of web browsers supported them.
Some level of programability between client and server was essential. Had the 'render only' view prevailed you wouldn't have Javascript either. But it didn't prevail.
That said, security has always had a sort of anti-thetical relationship with 'features.' Its easy to sell features and its hard to sell security. I had built the basics for a nice capabilities based security model for Java early on (even patented it with the NSA's approval), which created a durable way giving only specific capabilities to an applet in a way that made other capabilities not only not accessible but not even present in the running system.
It was a bit more complex than the way class loading had traditionally been envisioned, it really crushed my motivation when another engineer on the Java project deleted it out of the source tree because he couldn't understand it.
The point I make is that these things evolve, and the story is never as simple as it looked like once you've gotten to the end of it. Should I have pushed harder on conceptual security even though it was hurting my career? Probably. Would it change where we are today? Hard to say.
> the retards who thought applets were a good idea and going to revolutionize the Web
Didn't this happen? I mean, the "applets" we use are all called "Flash" and not "Java", but Flash is everywhere, from ads to video to music. When the so-called "retards" were envisioning a future web, I though that's what they wanted.
I would guess those Java "0-day" vulnerabilities have been known for months or years.
It's just that now, because of the previous spread of 2-3 vulnerabilities, the publicity and the extra scrutiny placed upon Java bugs by Oracle, those holding on to them started selling/using them in fear that they will be discovered and patched soon.
The best thing to happen to Java was Google supporting Android. Now we have probably 5 more years of this mess until we get good adoption of a real linux phone, then Java will be tossed onto the already rotting corpse of flash.
Hardly worth bothering to reply to this sort of nonsense, but applets are a tiny tiny fraction of a percent of what Java is used for. Java and other JVM languages are use in most backend systems today and also by the likes of google, amazon etc.
Java should change their logo from a coffee to some swiss cheese.
I want to know two things,
first: Why huge banks (the sort that net profit 10 billion) and other big organisations (like, governments) insist in using Java Applets for browser security and auth?
second: Why JVM is full of holes while JVM clones (like Dalvik and open source JVM substitutes for desktops) seemly are so much less affected?
I would put my money that Dalvik etc is not inherently safer, it's just a matter of the JVM holes being fairly executable-specific attacks, and nobody bothering to target the off-brand JVMs.
I'm with you on the first part -- certainly there's nothing inherently different between the interpreter security models of the JVM and Dalvik.
But if you're counting by deployed units, the JVM is now the "off brand". Dalvik owns that market. Certainly it's no less an attractive target -- perhaps more so as mobile devices are now a bigger part of the consumer market.
This isn't really targeting the same kind of thing. These are Java applet sandbox exploits. Android machines don't run Java code they find on web pages. These are the same thing as finding a bug in the Flash plugin or the browser.
I think security bugs in Dalvik have less ramifications, because of at least 2 reasons:
1. Java code doesn't get executed by Dalvik automatically from web sites etc - an attacker has to get the user to install his application.
2. If an attacker manages to get the user to install and run his application, Dalvik security bugs are close to useless to him because Android applications can load native code without needing permission from the user. His problem is going to be circumventing the restrictions enforced by the kernel and system daemons running on the system. Android doesn't enforce permissions at the JVM level AFAIK.
To clarify here I meant vulnerabilities in the JVM that have to be triggered by malicious Java bytecode. Vulnerabilities which make applications themselves vulnerable are more problematic of course.
Banks are notoriously bad about updating their technology practices. They didn't really stop using DES in their ATM's until it was required by law that they update to 3DES in 2002 (DES encryption has been theoretically broken since the 80's and practically, that is it was done in something like 17 days, broken since the 90's). For them, the potential losses from java exploits just don't outweigh the price of switching the infratstructure in place.
Has anyone from Sun/Oracle commented on this yet? Are certain parts of the code being exploited? Have they done anything to secure the VM? Is it all just spaghetti code at this point?
Anyone from Oracle who commented publicly on this would most assuredly be promptly fired and sued.
These Java exploits are all pretty low hanging fruit. CVE-2013-0431 basically boiled down to calling "System.setSecurityManager(null)". We haven't even hit the advanced stuff yet.
As for "boiling down to calling setSecurityManager(null)" you are forgetting to point out how it was achieved via obscure calls to an instrumentation and management api:
"The plan for Java security is really simple," said Java security lead Milton Smith during a conference call this week with Java user group leaders. "It's to get Java fixed up, number one, and then number two, to communicate our efforts widely. We really can't have one without the other. No amount of talking or smoothing over is going to make anybody happy. We have to fix Java." - See more at: http://www.computerworld.com/s/article/9236230/Oracle_s_Java...
> Do NOT install Java from your distro. Do NOT install Java by giving the root password (or by directly using the root account): no rpm, no deb.
This advice is fundamentally confused about how computer security works: the issue is not how the code is installed, it's whether an attacker can get your browser / email client to execute it. If the code runs as you, it has all the access it needs even if the files are owned by root.
> Fetch, from a regular user account, the Java .tar.gz and install Java in your dev user account.
So I don't get updates from the very responsive Ubuntu / Debian groups and instead rely on obsessively checking the news? That seems a LOT worse than simply disabling the Java browser plugin.
I dont understand all the fus around these exploits. Are they exploits? Yes. Do people actually use java in the web? Not really.
Maybe im in the minority but i never see java applets, and i think i browse ~ the avg. Of course i also disable all plugins until i click on something.
It makes no difference how prevalent they are in common web apps, the problem is that the Java plugin is still installed and active for a large number of users.
This is not the attack sequence:
* site has pre-existing Java
* site gets compromised somehow
* site now infects users
This is how it usually plays out:
* site gets compromised somehow
* exploit includes a 0-day Java attack
* site now infects users
Literally 0 sites on the net could be hosting Java applets and that would make no difference; it's the number of active Java plugins that creates the potential for mass-infection. So long as you have the Java plugin enabled, you'll be exposed to this attack.
Yes - also even a user who only wants to use client side Java outside of the browsers may be in trouble because of the automatically installed browser plugins that are part of the Java installation process.
It's incredible how far and fast client side Java has fallen because of Oracle's tepid response to security concerns. I've developed many internal apps for client-side Java and supported them for over a decade. I don't think I'll develop another.
It has nothing to do with Oracle's response -- the Java sandbox is simply broken, and has been known to be broken for at least the last 5 years. There's no fixing it, the approach is fundamentally flawed and fundamental to Java.
This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.
java sandbox has a massive surface area. conceivably any class in the jre could create a hole in the sandbox. modern browser sandboxes appear to be stronger because they rely on an unprivileged process which communicates with a broker interface. the broker code is much smaller than the jre code so it is easier to verify. however, there has been sandbox bypasses. the adobe sandbox bypass was a bug in the broker interface and it can be possible to use local kernel exploits to bypass the sandbox as well.
"This doesn't mean that Java for client-side applications is broken[...]"
I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.
I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people.
The less Java installed, the harder my life becomes ; (
Are there JREs which you can secretly include in your package, so that it looks like a few-hundred MB native application which happens to be implemented in Java?
User googles for 'digital camera nokia review' and ends up on a site containing a specially crafted 1x1 pixel Java applet. User doesn't even know it's there but due to the 0-day exploit, the applet can now download a remote executable to the user's machine and execute it. User's computer is now part of a botnet and all the user did was perform an innocuous google search.
Yes or it could be a site they visit regularly that has been hacked. Or a site that hasn't been hacked but that has JS from an ad network on it that has been hacked or let through a vulnerability. These are very scary hacks.
Update: I wrote up my recent experience of a shady advertising buy that appears to have spreading malware (likely via Java) as a goal http://news.ycombinator.com/item?id=5305092
Considering Facebook and Apple devs getting owned by these exploits I think the answer is yes. That you even know what a plug-in is does make you in the minority, but considering who has been victim so far you should not sit back with such a smug attitude.
If you visit a malicious site and click anywhere on the page (not on a plugin) then you could enable a click 2 play plugin. i raised this as a chrome bug and they said click 2 play is not a security feature. there may be even worse bypasses :(
the only way to have proper security is to disable the plugin. there is a button on the address bar that allows you to enable plugins on a page when they have been disabled. this gives you a similar experience to click2play but it is quite annoying especially if you are used to click2play.
I can't reply further down the comment thread, but can you provide an official source on this. I enabled this feature last week, and there's no way of interacting with the plugin until I click on it.
I'm SCJP since the last century and my life has been developing Java since a lloonngg time (and now Clojure, but targetting the JVM).
Honestly the retards who decided that a Java applet was a wise decision for a bank should be shot before their genes are passed to a new generation :-/
"You know, one of these days, we're going to use that second digit.” — Stephen Colbert