4 ms·

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.

by k3n 14y ago

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.

jug6ernaut 14y ago
Ah, fair enough.
sixbrx 14y ago
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.
- pifflesnort 14y ago
  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.
  - tjoff 14y ago
    "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.
    - sp332 14y ago
      Try installing using http://ninite.com http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.
  - BigBlueSaw 14y ago
    Can you elaborate on "the approach is fundamentally flawed"? Don't we rely on a similar sort of sandboxing for Javascript in the browser?
    - benmmurphy 14y ago
      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.
- martinced 14y ago
  Oh you don't know my misery : ( 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 ; (
  - limmeau 14y ago
    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?

by k3n 14y ago

jug6ernaut 14y ago

Ah, fair enough.

sixbrx 14y ago

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.

pifflesnort 14y ago
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.
- tjoff 14y ago
  "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.
  - sp332 14y ago
    Try installing using http://ninite.com http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.
- BigBlueSaw 14y ago
  Can you elaborate on "the approach is fundamentally flawed"? Don't we rely on a similar sort of sandboxing for Javascript in the browser?
  - benmmurphy 14y ago
    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.
martinced 14y ago
Oh you don't know my misery : ( 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 ; (
- limmeau 14y ago
  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?