5 ms·

Does this apply to server side java as well, or is it only the browser client crap that noone has used this decennium?

by yxhuvud 14y ago

spartango 14y ago
Client-side (browser-plugin) only: Java in the browser (applets, web start) runs in a plugin which is supposed to have a strong sandbox to prevent applications from doing things like touching files or controlling your window manager without your permission. On the server (or invoked from the commandline/jar), the security policy is much looser and there's no sandboxing (outside of what the OS and interpreter prevent).
- jiggy2011 14y ago
  Yes, although I would generally recommend running your server side Java software inside a chroot jail.
  - foohbarbaz 14y ago
    That's pretty silly. Why?
    - yuliyp 14y ago
      To be fair, running any internet-facing apps in a chroot jail is a good idea no matter which language they use.
    - jiggy2011 14y ago
      Isolation, helps to limit the damage done by a random bug or attack. Can also be useful when you have apps with weird dependencies.
sandbags 14y ago
I've asked the same question. I would guess the same vulnerability would be present but only exploitable if a Java app that you run somehow contains or downloads the malicious code. But any server/desktop app you run probably already has enough vectors to exploit your system.
foohbarbaz 14y ago
No, it does not. This is non-news. Agreed, nobody uses that anymore, nobody should.
- freehunter 14y ago
  All the people commenting on this saying Java is never used by anybody and no one should be having it installed are way off, seriously. There's a reason Java is #2 on the TIOBE language list. Just because you never see it doesn't mean it's not being used. You might not know this, but Gmail is Java powered on the backend. Many banking sites use Java for a backend. In the corporate world, Java rules and is required to be installed on their machines.
  - foohbarbaz 14y ago
    This has nothing to do with Java. It's a browser plugin issue. Disable the plugin and forget.
    - freehunter 14y ago
      You must have missed my last sentence. People work at the companies who are running Java on the server. People work at the companies who are developing Java on the desktop. A lot of people. A significant enough number of people that the language makes #2 on the TIOBE list. Debates about the TIOBE relevancy aside, it's at least somewhat of an indicator. People are working for companies that use Java, and these employees cannot disable Java in their browser because it's required for their job. I happen to work at one of these shops, and I can confirm to you 12,000 people in the US from just my company alone who must have Java in their browser and running constantly. We're not alone in this regard. We're all vulnerable, and the suggestion to disable the plugin doesn't help much.
    - mrgoldenbrown 14y ago
      OK. I took your advice. Except I couldn't forget because now my VPN client, gotomeeting, and various internal enterprisey things all stopped working :)
- 14y ago
MichaelGG 14y ago
Seems like it applies to Java, period. So yes, could affect servers. It's another sandboxing bypass. It's just unlikely that you're depending on sandboxing on servers, unless you're running some shared environment with untrusted code from third-parties. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4681 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-468... "bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields"
- foohbarbaz 14y ago
  Sandboxing in JVM is broken. Server code does not rely on that (most of the time). Sandboxing is inherently insecure. It usually comes with appropriate warnings (ex: Python) and everybody is expected to understand that it is a half measure at best.
mrgoldenbrown 14y ago
Except anybody that use gotomeeting, any number of VPN applications, and any number of enterprise applications, or lives in countries whose official government web sites still use applets, etc etc etc.

Does this apply to server side java as well, or is it only the browser client crap that noone has used this decennium?

by yxhuvud 14y ago

Does this apply to server side java as well, or is it only the browser client crap that noone has used this decennium?

Client-side (browser-plugin) only: Java in the browser (applets, web start) runs in a plugin which is supposed to have a strong sandbox to prevent applications from doing things like touching files or controlling your window manager without your permission. On the server (or invoked from the commandline/jar), the security policy is much looser and there's no sandboxing (outside of what the OS and interpreter prevent).

jiggy2011 14y ago
Yes, although I would generally recommend running your server side Java software inside a chroot jail.
- foohbarbaz 14y ago
  That's pretty silly. Why?
  - yuliyp 14y ago
    To be fair, running any internet-facing apps in a chroot jail is a good idea no matter which language they use.
  - jiggy2011 14y ago
    Isolation, helps to limit the damage done by a random bug or attack. Can also be useful when you have apps with weird dependencies.

sandbags 14y ago

I've asked the same question. I would guess the same vulnerability would be present but only exploitable if a Java app that you run somehow contains or downloads the malicious code. But any server/desktop app you run probably already has enough vectors to exploit your system.

foohbarbaz 14y ago

No, it does not. This is non-news. Agreed, nobody uses that anymore, nobody should.

freehunter 14y ago
All the people commenting on this saying Java is never used by anybody and no one should be having it installed are way off, seriously. There's a reason Java is #2 on the TIOBE language list. Just because you never see it doesn't mean it's not being used. You might not know this, but Gmail is Java powered on the backend. Many banking sites use Java for a backend. In the corporate world, Java rules and is required to be installed on their machines.
- foohbarbaz 14y ago
  This has nothing to do with Java. It's a browser plugin issue. Disable the plugin and forget.
  - freehunter 14y ago
    You must have missed my last sentence. People work at the companies who are running Java on the server. People work at the companies who are developing Java on the desktop. A lot of people. A significant enough number of people that the language makes #2 on the TIOBE list. Debates about the TIOBE relevancy aside, it's at least somewhat of an indicator. People are working for companies that use Java, and these employees cannot disable Java in their browser because it's required for their job. I happen to work at one of these shops, and I can confirm to you 12,000 people in the US from just my company alone who must have Java in their browser and running constantly. We're not alone in this regard. We're all vulnerable, and the suggestion to disable the plugin doesn't help much.
  - mrgoldenbrown 14y ago
    OK. I took your advice. Except I couldn't forget because now my VPN client, gotomeeting, and various internal enterprisey things all stopped working :)
14y ago

MichaelGG 14y ago

Seems like it applies to Java, period. So yes, could affect servers. It's another sandboxing bypass. It's just unlikely that you're depending on sandboxing on servers, unless you're running some shared environment with untrusted code from third-parties. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4681 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-468... "bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields"

foohbarbaz 14y ago
Sandboxing in JVM is broken. Server code does not rely on that (most of the time). Sandboxing is inherently insecure. It usually comes with appropriate warnings (ex: Python) and everybody is expected to understand that it is a half measure at best.

mrgoldenbrown 14y ago

Except anybody that use gotomeeting, any number of VPN applications, and any number of enterprise applications, or lives in countries whose official government web sites still use applets, etc etc etc.