Slashdot Mirror
A Tidal Wave of Java Flaw Exploitation
tsu doh nimh writes "Microsoft warned today that it is witnessing a huge spike in the exploitation of Java vulnerabilities on the Windows platform, and that attacks on Java security holes now far outpace the exploitation of Adobe PDF bugs. The Microsoft announcement cites research by blogger Brian Krebs, who has been warning for several months that Java vulnerabilities are showing up as the top moneymakers for those peddling commercial crimeware exploitation kits, such as Eleonore, Crimepack and SEO Sploit Pack."
Several days ago, Oracle released a patch that fixed 29 Java security flaws.
The one question this article doesn't really clarify is pretty important: How are these exploits being loaded onto the user's computer?
Are we talking applets, Java web start, or some other mechanism?
There's no -1 for "I don't get it."
People are angry at Oracle for screwing Sun so they are writing exploits for revenge.
For reasons I have never been able to figure out, Java has significant issues auto updating on all my home Windows computers (XP, Vista, and 7). Sure enough, just last week I had to spend a night sanitizing one of the systems, for now I've uninstalled Java until I have the chance to figure out just what the problem is but honestly not having it hasn't been a problem so I'll probably just leave it off until I find something that actually requires it.
Java updates contain unrelated bugfixes and functionality, breaking applications. They are far from being minimal updates. Back in the Sun days, this was addressed by enabling parallel installation of many JVM versions. It was even possible for web content to request a specific JVM version, which means that you actually had to update to a newer version and delete all the old versions. I'm not complete sure that this part has actually been addressed. It's certainly a problem for those who still need to use Java 1.4 or Java 5 (which are out of security support now, but are still widely mandated in the industry).
This creates a huge issue for the company I provide support for. We have so far not updated beyond 6u20. That is the last version of the JVM to carry the "Sun Microsystems" label instead of something referencing Oracle.
Some divisions of this company (and I would assume others as well) still run apps that seem to be incompatible with anything above 6u20 for this reason. Oracle's poor stewardship toward the Java platform has lead to a situation where we will have to make a decision on a per workstation basis whether to lose access to some important applications, or remain vulnerable to Java exploits for an unknown and possibly indefinite period of time.
What's annoying is there is no real "patch" as such. You have to install the entire 77mb package from scratch and it installs crap like the yahoo toolbar by default.
The best solution then is to leave it uninstalled permanently. I mean really what do you need it for on a home machine? It's not like there are any apps that need it.
He seemed pretty accurate other than some exaggeration. If you want to see a "Massive amount of crapware" buy a PC from a big box store, not "java tried to install the yahoo toolbar boo hoo".
The funniest Java related thing I've seen, is amongst the non-computer cow orkers "Oh man, another java program, that thing is gonna be slow and take IT forever to install (actually they mean the JVM) and crash all the time". Computer people have known that for over a decade now, the funny part is hearing non computer people start to complain.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
If the infections were coming via Java Applets then it becomes pertinent to ask how did they get on the machine. Java appplets must be signed to write to the user's hard drive. This means the user was prompted to approve an untrusted certificate and they did so, or the malware organisation had a trusted certificate, in which case the trust authority should revoke the certificate. It is not like applets are without protection to the end user.
Two of the three cited vulns aren't actually buffer overflows. It's badly written Java code that other Java code can exploit to escape from the sandbox.