It's about time: Java update includes tool for blocking drive-by exploits Oracle's latest update to the Java SE Development Kit (JDK) version 7 adds new security features designed to help businesses avoid being stung by critical vulnerabilities in out-of-date versions of Java. After a string of embarrassing Java security flaws was disclosed by independent researchers, Oracle has made addressing …
I know Java was popular for bit companies custom IT systems to (in theory) simplify migration issues.
But if most of the issues are with the the Jave browser plug it would seem (if you can't disable them outright) that you need strong URL management at the very least.
With Java/VBScript now merged under ECMAScript is it not time for Oracle to hand over Java to ISO?
The usual confusion, java != javascript
Java is a system where compiled bytecode runs under a runtime environment.
Javascript/VBscript is now merged under ECMAScript and is an interpreted script language.
The Java browser plugin hands off the execution to the Java runtime environment installed on your computer
ECMAScript runs within the browser
"The usual confusion, java != javascript"
Wrong.
I'm very well aware that they are not the same. My point was that as Javascript and VBscript now exist as a common language as both an ECMA and ISO standard, and I suggest that if Java were also brought as a standard under ISO more outfits might be willing to over better JVM's other than Oracle.
That's what is called an analogy for people who have comprehension issues.
"The Java browser plugin hands off the execution to the Java runtime environment installed on your computer"
I'll quote the article.
"most of which attack systems via the Java web plugin and do not affect server-side Java applications or desktop applications installed on the local machine."
I read the article and commented.
Perhaps you should have done the same.
There are plenty of JVMs out there. Not sure what over a better grocer's apostrophe JVM will do though.
The browser plugin executes a java applet in a sandbox in a JVM running in a separate process. The same JVM installed on your machine (or one of therm). The same JVM is used to execute Java applications that can run as desktop, background or server applications.
All unpatched versions of Java have the vulnerability. The problem is caused when malware Java code runs on such a JVM. Downloading a dodgy Java application, running a dodgy jar in your server application or running a dodgy java applet can all exploit these vulnerabilities. The browser plugin simply provides the simplest route to get such malware code on your machine.
<quote>But many businesses still keep older versions of Java installed on client PCs because certain custom applications require them.</quote>
I find Java 6 still installed on many PCs because the average user doesn't know if they need it or not. Usually I find an out of date Java 6 alongside an out of date Java 7 (Are we REALLY up to Update 40 already?)
Those old Java 6's are still there as Java 7 doesn't even bother to give an option to remove the old versions. And Java 7 is always out of date as the average user gets bored of being nagged so often to perform an update.
And I hope this new Whitelist is extremely secure. And not something that can just be updated by the infection to give itself permission...
The sooner Java is put out of its misery, the better. The current owners clearly don't have the skill set to look after it properly. The sheer scale of troubles it has caused in the past years is beyond a joke now.
Why is Java still so insecure and always has been? And more importantly why the hell does anyone still use anything with such a demonstrable history of being crap?
I don't hear about anyone's PC being hit by Drive By .Net exploits, even though .Net is installed on far more PCs....
Java itself is not insecure. No more or less than any other language. A Java Application is executed with the rights of the user starting it, just like any other program and can do the same damage as any other program no matter of the language. There are no holes an attacker can exploit.
The Java Plugin has security problems. It is used to run Applets within a browser. Normally those applets are very restricted in their permissions, basically "show up" but can ask for more up to the full user rights. The security holes allow them to do that without the users knowledge.
There is no direct equivalent to an Applet in .NET so there is no equivalent exploit. And IE has various other holes that are easily exploitet.
The Java Plugin is easily disabled without disabling JAVA itself so Applications run fine will Applets won't so the danger is very limited
Joe Q. Public, an IT luser is happy with his 7 year old PC, but an app tells him to update Java.
After a quick search, he goes to the old java.sun.com and starts to scratch his head between the "top downloads" and "new dowloads"... and wonders WTF the difference is between Java SE, EE, FX, ME, ADF, IDE and VM.... one is called Java SE 7 Update 40, Update sounds good, so lets click and pray.
Next screen, tells us about the JDK or JDK & Netbeans, below, JDK, Server JRE or JRE... He has stopped scratching his head and is now totally confused. He clicks on the first link Java Platform (if he is lucky), or Next Releases (where is will drown in TLA soup and die).
So on the Java page, he looks at a huge list of Java for ARM, for Linux 86 & 64 & tar or rpm, Mac, Solaris, Sparc or windows... if he is unlucky he scrolls down and finds the same list for Java + demos and maybe even JavaFX. He clicks on the first one for ARM, gets a popup telling him he forgot to accept the licence, he hunts for that, then reclicks, downloads a version for ARM or Linux, and from there, best case is that he is happy that he updated his Java as he now has a zip file in his download folder. Worst case, he will attempt to install, it fails and then goes and tell all his mates that this java stuff is a load of bollyhocks and gives up...
This feature has been needed for a long time. Finally we can control what gets run (from what I understand so far).
RIA's are important apps, not replaceable by simple HTML5 solutions. Some of Java (JWS), some are Silverlight. We can't just block them all, but uncontrolled executable code on clients has always been an issue. No more, so it seams in Java. About time...
Will considering Silverlight and .Net are installed on pretty much ever Windows PC, if those bugs were actually realistically exploitable (e.g. just visit a web page) then I would have expected to see exploits. But I havn't....which says to me that Java's security sucks a lot more...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
