Linked by Hadrien Grasland on Thu 20th Jan 2011 21:16 UTC
Permalink for comment 459313
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2005-07-08
The main problem is that most JVMs are implemented in C or C++. The languages responsible for bringing a dark era of buffer overruns and pointer mis-indirections to mankind, thus starting an era of insecure software, which we still fight to recover from.
One just needs to create a clever designed sequence of bytes as a .class file that exploits a security issue in a specific JVM version. Then you release the exploit in the wild and for sure a few thousand users will be hit.
As for the users not updating it. It is really a big issue, in most corporate environments there is a big burocracy that you need to go through to update any software, even patch level versions.
Most corporate environments I know, the automatic updates are disabled, and updates are triggered by IT when they approved a certain software version.
Not to mention that recently I saw an offer for a project using Java 1.4 with Tomcat 4!