4 ms·

Java should change their logo from a coffee to some swiss cheese. I want to know two things, first: Why huge banks (the sort that net profit 10 billion) and o

by speeder 14y ago

Java should change their logo from a coffee to some swiss cheese. I want to know two things, first: Why huge banks (the sort that net profit 10 billion) and other big organisations (like, governments) insist in using Java Applets for browser security and auth? second: Why JVM is full of holes while JVM clones (like Dalvik and open source JVM substitutes for desktops) seemly are so much less affected?

IvyMike 14y ago
I would put my money that Dalvik etc is not inherently safer, it's just a matter of the JVM holes being fairly executable-specific attacks, and nobody bothering to target the off-brand JVMs.
- ajross 14y ago
  I'm with you on the first part -- certainly there's nothing inherently different between the interpreter security models of the JVM and Dalvik. But if you're counting by deployed units, the JVM is now the "off brand". Dalvik owns that market. Certainly it's no less an attractive target -- perhaps more so as mobile devices are now a bigger part of the consumer market.
  - spullara 14y ago
    This isn't really targeting the same kind of thing. These are Java applet sandbox exploits. Android machines don't run Java code they find on web pages. These are the same thing as finding a bug in the Flash plugin or the browser.
- ambrop7 14y ago
  I think security bugs in Dalvik have less ramifications, because of at least 2 reasons: 1. Java code doesn't get executed by Dalvik automatically from web sites etc - an attacker has to get the user to install his application. 2. If an attacker manages to get the user to install and run his application, Dalvik security bugs are close to useless to him because Android applications can load native code without needing permission from the user. His problem is going to be circumventing the restrictions enforced by the kernel and system daemons running on the system. Android doesn't enforce permissions at the JVM level AFAIK. To clarify here I meant vulnerabilities in the JVM that have to be triggered by malicious Java bytecode. Vulnerabilities which make applications themselves vulnerable are more problematic of course.
kedean 14y ago
Banks are notoriously bad about updating their technology practices. They didn't really stop using DES in their ATM's until it was required by law that they update to 3DES in 2002 (DES encryption has been theoretically broken since the 80's and practically, that is it was done in something like 17 days, broken since the 90's). For them, the potential losses from java exploits just don't outweigh the price of switching the infratstructure in place.

by speeder 14y ago

IvyMike 14y ago

I would put my money that Dalvik etc is not inherently safer, it's just a matter of the JVM holes being fairly executable-specific attacks, and nobody bothering to target the off-brand JVMs.

ajross 14y ago
I'm with you on the first part -- certainly there's nothing inherently different between the interpreter security models of the JVM and Dalvik. But if you're counting by deployed units, the JVM is now the "off brand". Dalvik owns that market. Certainly it's no less an attractive target -- perhaps more so as mobile devices are now a bigger part of the consumer market.
- spullara 14y ago
  This isn't really targeting the same kind of thing. These are Java applet sandbox exploits. Android machines don't run Java code they find on web pages. These are the same thing as finding a bug in the Flash plugin or the browser.
ambrop7 14y ago
I think security bugs in Dalvik have less ramifications, because of at least 2 reasons: 1. Java code doesn't get executed by Dalvik automatically from web sites etc - an attacker has to get the user to install his application. 2. If an attacker manages to get the user to install and run his application, Dalvik security bugs are close to useless to him because Android applications can load native code without needing permission from the user. His problem is going to be circumventing the restrictions enforced by the kernel and system daemons running on the system. Android doesn't enforce permissions at the JVM level AFAIK. To clarify here I meant vulnerabilities in the JVM that have to be triggered by malicious Java bytecode. Vulnerabilities which make applications themselves vulnerable are more problematic of course.

kedean 14y ago

Banks are notoriously bad about updating their technology practices. They didn't really stop using DES in their ATM's until it was required by law that they update to 3DES in 2002 (DES encryption has been theoretically broken since the 80's and practically, that is it was done in something like 17 days, broken since the 90's). For them, the potential losses from java exploits just don't outweigh the price of switching the infratstructure in place.