Java Primary Cause of 91 Percent of Attacks: Cisco(eweek.com)
eweek.com
Java Primary Cause of 91 Percent of Attacks: Cisco
http://www.eweek.com/security/java-primary-cause-of-91-percent-of-attacks-cisco.html
10 comments
First step would be to keep the deskop clean from C.
Can somebody update the title with something like: "The Java browser plugin cause..."?
sadly the damage is already done. i remember a year ago the department of health in louisiana would choose sharepoint 2010 over anything with a java backend because they thought java was too insecure.
Somehow Sun is the one to blame here, by having the great idea of calling everything just Java on the Java ecosystem.
If this confuse us with deep computing knowledge, what to say from the average public.
If this confuse us with deep computing knowledge, what to say from the average public.
I fail to see what the problem is
The company developing the Java browser plugin is the same that develops the Java Runtime.
Problems arise from lack of validation of untrusted data, be that either coming from a webpage or a request to a server.
The company developing the Java browser plugin is the same that develops the Java Runtime.
Problems arise from lack of validation of untrusted data, be that either coming from a webpage or a request to a server.
I wonder if the NSA pays (directly or indirectly) Oracle to slow walk these Java applet vulnerability updates.
How many of these are OS-specific? I run OpenJDK on Linux - how much should I worry?
The sandbox bypass vulns almost always also affect OpenJDK and IBM JVM.
Your best bet is to keep the Java browser plugin disabled as much as you possibly can, no matter your OS or browser.
Your best bet is to keep the Java browser plugin disabled as much as you possibly can, no matter your OS or browser.
the Java part of the attack is usually cross platform, depends what payloads they add after that. I would not rely on it...
I had hopes it depended on the N part of JNI. I guess the plug-in will continue disabled on my main browser.
It's particularly distressing since the only real use the plugin gets is on the banking and government sites I have to use :-( where a such major screw up is exceedingly major.
It's particularly distressing since the only real use the plugin gets is on the banking and government sites I have to use :-( where a such major screw up is exceedingly major.
But Java is "enterprise"!!!1
From working incident response and malware remediation in a fairly large company, I can definitely corroborate that statistic.
Was the article clear but I missed it? The problem is the Java browser plugin, not Java proper, right? Does anyone have any examples of Java proper not being secure?
Even more bizarre, at least to me, is this quote:
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained.
What?
Even more bizarre, at least to me, is this quote:
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained.
What?
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained.
What?
This was addressed on reddit [1]:
What?
This was addressed on reddit [1]:
Since I'm the person who submitted this data
for the annual security report inside of Cisco
and also have the interviews surrounding this...
91% of client side compromises had to do with
the java plugin to the browser. Java applets,
not server side java.
Sometimes JavaScript is used to obfuscate the applet,
the applet load, or the entire page, the vulnerability
is not in JavaScript.
The Java browser plugin runs unsigned applets in a sandbox. Sandboxed applications can only use a subset of Java that should make it impossible to cause serious damage to the host system. However, if an attacker can break out of the sandbox, they can do whatever they want, so this is a pretty common attack vector.
If you're interested, I spent some time figuring out how these attacks work and I blogged about it here: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...
If you're interested, I spent some time figuring out how these attacks work and I blogged about it here: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...
What's the difference between that and running JavaScript unfettered? If the confines of the Java Sandbox can be challenged by hackers, JavaScript's day is coming and it will be huge.
The difference is that Javascript generally has no API for accessing file system and OS resources, but Java applets by default give full access to the entire Java standard library; it simply restricts certain parts of it with the sandbox. If a Java applet can find a way to access things on the blacklist, then it can download and run any file with your OS user privileges.
With Javascript there isn't actually a sandbox to break out of.
With Javascript there isn't actually a sandbox to break out of.
> API for accessing file system and OS resources
You mean like FileReader and WebGL/CL?
You mean like FileReader and WebGL/CL?
And so it can be exploited:
http://www.scip.ch/en/?vuldb.10561
http://www.scip.ch/en/?vuldb.10561
This is a buffer overflow exploit in the browser, not an exploit of the API mechanics. On the other hand, most critical Java vulnerabilities are simple sandbox bypasses, not memory corruption ones.
> Java vulnerabilities are simple sandbox
On Oracle's implementation. There are other JVMs to choose from.
Plus, can you guarantee that the JavaScript sandbox from all VMs are safe if hackers turn their attention to them?
On Oracle's implementation. There are other JVMs to choose from.
Plus, can you guarantee that the JavaScript sandbox from all VMs are safe if hackers turn their attention to them?
IBM's JVM and OpenJDK's IcedTea have fallen victim to most (possibly all, not sure) of the exact same sandbox bypass flaws as the ones in Oracle's HotSpot, mostly because the codebase of all the other alternatives still contains a huge portion of Oracle's original code.
Is there an implementation of the JVM in Javascript? That should address some of the issues outlined.
> What's the difference between that and running JavaScript unfettered?
Except that the article is specifically about the Java plugin for browsers.
But, that said, the fact that there have been so many Java exploits reported compared to JavaScript exploits probably says a lot about the major browser developers (Mozilla, Google, Apple, Microsoft) compared to Oracle/Sun.
Except that the article is specifically about the Java plugin for browsers.
But, that said, the fact that there have been so many Java exploits reported compared to JavaScript exploits probably says a lot about the major browser developers (Mozilla, Google, Apple, Microsoft) compared to Oracle/Sun.
Not necessarily: it seems that the poor quality of specifically the Java sandbox and its security maintenance are the main problem here.
>Does anyone have any examples of Java proper not being secure?
What would Java proper being insecure look like. If your code is running in a normal JVM, then you can already write arbitrary data to a file and simply exec it, trivially giving you arbitrary code execution without breaking any part of the run-time.
What would Java proper being insecure look like. If your code is running in a normal JVM, then you can already write arbitrary data to a file and simply exec it, trivially giving you arbitrary code execution without breaking any part of the run-time.
Yes, I understand. The point being that this article is about the Java browser plugin and security vulnerabilities surrounding that particular part of Java and being conflated to Java in the large. The article does a poor job of pointing this out and seems inflammatory.
Insecure networked Java means that (hypothetically, or with that floating point parse bug of ~2011), user input could cause a program to behave in ways not intended by the author. Insecure "local" Java would be something like an equivalent of XSRF , mixing data from multiple sources in unintended ways, or leaking data from your user account/ security context to a place visible by other accounts/roles on the system.
Well there are other uses of the Java sandbox, although not many.
That quote does seem off. Minified & concatenated JavaScript is pretty common these days. How many sites are serving up jQuery, unminified?
Yeah, I agree with you, but what does that quote in this article have anything to do with Java security issues?
Though sometimes it seems that the JavaScript malware "obfuscations" appear to be more incriminating than if they had used legitimate obfuscations, right? At least every time I look at some post on a blog about malware it seems that the malware author could have benefitted from some sort to standard obfuscation technique like grunt, etc.
Though sometimes it seems that the JavaScript malware "obfuscations" appear to be more incriminating than if they had used legitimate obfuscations, right? At least every time I look at some post on a blog about malware it seems that the malware author could have benefitted from some sort to standard obfuscation technique like grunt, etc.
Yes it sounds like it's primarily about the Java browser plugin, based on the examples in the article.
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained.
Those make sense as example heuristics for detecting malware-serving sites. What part doesn't make sense? I don't know of legitimate websites that obfuscate their JS. (Minification doesn't count.) Presumably they've found malware websites in the wild that obfuscate.
Redirecting users in a jarring way is something malware sites actually do. Like going to example.com and it immediately redirects you to adsfa8sdjfa9sd8jfasd.com. The security guy isn't saying redirects are categorically bad, just that it's another heuristic that raises the chance you're currently viewing a malicious site.
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained.
Those make sense as example heuristics for detecting malware-serving sites. What part doesn't make sense? I don't know of legitimate websites that obfuscate their JS. (Minification doesn't count.) Presumably they've found malware websites in the wild that obfuscate.
Redirecting users in a jarring way is something malware sites actually do. Like going to example.com and it immediately redirects you to adsfa8sdjfa9sd8jfasd.com. The security guy isn't saying redirects are categorically bad, just that it's another heuristic that raises the chance you're currently viewing a malicious site.
> I don't know of legitimate websites that obfuscate their JS. (Minification doesn't count.)
What exactly is the difference between obfuscation and minimization? Could you write a program to tell the difference between a JS file that's been benevolently minified versus maliciously obfuscated? For that matter, how do humans tell the difference between minification and obfuscation?
I think that, if you define "obfuscation" as "transforming source code into a less readable form," then most automatic program transformations -- especially those specifically intended to reduce the size of the resulting code -- will also be obfuscations.
Of course, if only malware authors would make their products comply with RFC 3514, these problems would go away; security sandboxes and antimalware programs could simply and effectively filter based on the intent of a program's author, rather than static or dynamic analysis of the program's code [1].
[1] http://tools.ietf.org/html/rfc3514
What exactly is the difference between obfuscation and minimization? Could you write a program to tell the difference between a JS file that's been benevolently minified versus maliciously obfuscated? For that matter, how do humans tell the difference between minification and obfuscation?
I think that, if you define "obfuscation" as "transforming source code into a less readable form," then most automatic program transformations -- especially those specifically intended to reduce the size of the resulting code -- will also be obfuscations.
Of course, if only malware authors would make their products comply with RFC 3514, these problems would go away; security sandboxes and antimalware programs could simply and effectively filter based on the intent of a program's author, rather than static or dynamic analysis of the program's code [1].
[1] http://tools.ietf.org/html/rfc3514
> What part doesn't make sense?
The part where the article is about Java security vulnerabilities and instead switches to talking about JavaScript, as if they were the same thing?
I get the difference and don't need the education. I was wondering what this had to do with Java. If you care to explain that, I'll be happy to hear it ;)
The part where the article is about Java security vulnerabilities and instead switches to talking about JavaScript, as if they were the same thing?
I get the difference and don't need the education. I was wondering what this had to do with Java. If you care to explain that, I'll be happy to hear it ;)
> At the top of the list is a need for some form of behavior detection that monitors a user's chain of events before they land on an exploit. "For example, is a user requesting a Web page that included obfuscated JavaScript, and is the user being redirected?" Gundert asked.
The article is about Java exploits, and then they discuss the potential to recognize what happens before the payload is delivered.
If the web page includes obfuscated JavaScript, and the user is then redirected, that could be a sign that a (probably Java) exploit is in the user's near future.
The article is about Java exploits, and then they discuss the potential to recognize what happens before the payload is delivered.
If the web page includes obfuscated JavaScript, and the user is then redirected, that could be a sign that a (probably Java) exploit is in the user's near future.
> If the web page includes obfuscated JavaScript
Ok, but how do you know that "obfuscated JavaScript" is "bad"? I obfuscate all of my javascript, it's called minimization, that's now inherently bad?
Maybe browsers should require approval of redirects? Or make it an option? I mean that technique could apply to any sort of browser plugin (flash, or anything, not just java), what does obfuscated JavaScript have to do with redirects or Java in particular? The article is just being dishonest. I don't disagree that the Java plugin has had issues, but JavaScript redirects have nothing to do with it.
Don't get me wrong, there are tons of inherent risks to the online experience, but let's not make shit up at the same time! Which is what it seems this article does.
Ok, but how do you know that "obfuscated JavaScript" is "bad"? I obfuscate all of my javascript, it's called minimization, that's now inherently bad?
Maybe browsers should require approval of redirects? Or make it an option? I mean that technique could apply to any sort of browser plugin (flash, or anything, not just java), what does obfuscated JavaScript have to do with redirects or Java in particular? The article is just being dishonest. I don't disagree that the Java plugin has had issues, but JavaScript redirects have nothing to do with it.
Don't get me wrong, there are tons of inherent risks to the online experience, but let's not make shit up at the same time! Which is what it seems this article does.
> The problem is the Java browser plugin, not Java proper, right?
Clueless Java bashing as usual. Nobody uses Java applets any more.
Clueless Java bashing as usual. Nobody uses Java applets any more.
Oh really? Cisco Webex (Java) is IMHO still unbeaten by JS solutions like Google Hangouts[1] or JoinMe[2], despite its old-fashioned L&F. Also, what about banks in Norway?
[1] Fast refresh, but poor image quality. [2] Terribly slow refresh, audio doesn't work on Linux, needs to use skype/phone.
[1] Fast refresh, but poor image quality. [2] Terribly slow refresh, audio doesn't work on Linux, needs to use skype/phone.
There have been numerous classloader bugs and sandbox bypasses, right? Most of the time this doesn't matter since you're not sandboxing non-browser code.
Define "Java proper".
The article focuses on Java implementations being exploited without going into root causes behind the vulnerabilities.
Skimming http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java I'd say there's evidence of fundamental problems, affecting Java insomuch as they influence Java's API design:
- Huge attack surface (including native code in implementations)
- Insufficiently defensive API design
- Opt-into security ethos ("remember to escape, verify required permissions") rather than opt-out ("remember to unfreeze, untaint, verify unrequired permissions")
The article focuses on Java implementations being exploited without going into root causes behind the vulnerabilities.
Skimming http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java I'd say there's evidence of fundamental problems, affecting Java insomuch as they influence Java's API design:
- Huge attack surface (including native code in implementations)
- Insufficiently defensive API design
- Opt-into security ethos ("remember to escape, verify required permissions") rather than opt-out ("remember to unfreeze, untaint, verify unrequired permissions")
> Define "Java proper".
Java not running in the browser, i.e. running as a service on the target platform.
Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
Java not running in the browser, i.e. running as a service on the target platform.
Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
> Java not running in the browser, i.e. running as a service on the target platform.
Thank you for clarifying - my initial interpretation was wildly off.
> Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
I'm afraid I lack the practical detail you're probably after in terms of defending or mitigating attacks against Java services. Sorry! Some of the CVEs would still seem relevant, but you'd be better off turning to them directly instead of having me poorly parrot them.
Thank you for clarifying - my initial interpretation was wildly off.
> Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
I'm afraid I lack the practical detail you're probably after in terms of defending or mitigating attacks against Java services. Sorry! Some of the CVEs would still seem relevant, but you'd be better off turning to them directly instead of having me poorly parrot them.
The problem is that Java has consistently failed to be secure enough to safely execute untrusted code, that is code coming from unknown, potentially hostile sources.
For running trusted code, Java is fine.
For running trusted code, Java is fine.
Yes. And cars primary cause of 91 percent of car accidents.
IMO, Java in its own interest should not install/enable the Java browser plugin by default after installation of a JRE.
Java as a browser plugin is outdated in this decade of HTML5. Sure, it might be irreplaceable in some niches; for those users, the plugin could be made available as a separate installation.
Sadly, I am not hopeful that Oracle will lead the way here. They are going the other way and installing third-party utilities (the Ask.com toolbar) while installing Java.
Java as a browser plugin is outdated in this decade of HTML5. Sure, it might be irreplaceable in some niches; for those users, the plugin could be made available as a separate installation.
Sadly, I am not hopeful that Oracle will lead the way here. They are going the other way and installing third-party utilities (the Ask.com toolbar) while installing Java.
I think they are already going to default to only running signed applets in a a future update.
Those changes were released in Java 7u51 just last week. But it will take a long time for everyone to upgrade (if ever). It is possible to completely disable Java in the browser, but it takes some work (often you have to find a link in the browser's installation directory).
After reading your comment I went to the control panel of java and there you can at least disable the browser plugin. But removing it entirely would be better
Server-side, it's quite strong and capable, but client-side Java has proven itself to be a significant security threat. And as stated by 'hrjet' there is no significant reason to use Java in the browser anymore. Organisations still relying on legacy applications requiring old Java versions should really look into their priorities.
For companies it may be wise to only install Java on a few terminal servers / citrix servers (closely monitored, no internet access) and keep the user desktop clean from Java.