6 ms·

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

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?

MaulingMonkey 13y ago
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 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")
- craigching 13y ago
  > 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.
  - gsg 13y ago
    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.
  - MaulingMonkey 13y ago
    > 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.
ChrisAntaki 13y ago
That quote does seem off. Minified & concatenated JavaScript is pretty common these days. How many sites are serving up jQuery, unminified?
- craigching 13y ago
  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.
talklittle 13y ago
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.
- craigching 13y ago
  > 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 ;)
  - dminor 13y ago
    > 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.
    - craigching 13y ago
      > 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.
jsaxton86 13y ago
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-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...
- jebblue 13y ago
  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.
  - craigching 13y ago
    > 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.
  - meowface 13y ago
    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.
    - kleiba 13y ago
      Is there an implementation of the JVM in Javascript? That should address some of the issues outlined.
gizmo686 13y ago
>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.
- craigching 13y ago
  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.
- justincormack 13y ago
  Well there are other uses of the Java sandbox, although not many.
- gohrt 13y ago
  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.
MichaelGG 13y ago
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.
nhebb 13y ago
> 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]: 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. [1] http://www.reddit.com/r/programming/comments/1vj917/java_primary_cause_of_91_percent_of_attacks_cisco/cesybqn http://www.reddit.com/r/programming/comments/1vj917/java_pri...
ExpiredLink 13y ago
> The problem is the Java browser plugin, not Java proper, right? Clueless Java bashing as usual. Nobody uses Java applets any more.
- pkolaczk 13y ago
  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.

MaulingMonkey 13y ago

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

craigching 13y ago
> 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.
- gsg 13y ago
  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.
- MaulingMonkey 13y ago
  > 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.

ChrisAntaki 13y ago

That quote does seem off. Minified & concatenated JavaScript is pretty common these days. How many sites are serving up jQuery, unminified?

craigching 13y ago
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.

talklittle 13y ago

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.

craigching 13y ago
> 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 ;)
- dminor 13y ago
  > 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.
  - craigching 13y ago
    > 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.

jsaxton86 13y ago

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-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...

jebblue 13y ago
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.
- craigching 13y ago
  > 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.
- meowface 13y ago
  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.
  - kleiba 13y ago
    Is there an implementation of the JVM in Javascript? That should address some of the issues outlined.

gizmo686 13y ago

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

craigching 13y ago
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.
justincormack 13y ago
Well there are other uses of the Java sandbox, although not many.
gohrt 13y ago
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.

MichaelGG 13y ago

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.

nhebb 13y ago

> 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]: 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. [1] http://www.reddit.com/r/programming/comments/1vj917/java_primary_cause_of_91_percent_of_attacks_cisco/cesybqn http://www.reddit.com/r/programming/comments/1vj917/java_pri...

ExpiredLink 13y ago

> The problem is the Java browser plugin, not Java proper, right? Clueless Java bashing as usual. Nobody uses Java applets any more.

pkolaczk 13y ago
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.