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?
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.
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...
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.
With Javascript there isn't actually a sandbox to break out of.
You mean like FileReader and WebGL/CL?
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?
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.
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.
> 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.
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 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.
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.
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].
Clueless Java bashing as usual. Nobody uses Java applets any more.
[1] Fast refresh, but poor image quality. [2] Terribly slow refresh, audio doesn't work on Linux, needs to use skype/phone.
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")
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.
For running trusted code, Java is fine.
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.