Slashdot Mirror
Oracle Fixes Java Vulnerability Used By Russian Cyberspies (itworld.com)
itwbennett writes: Oracle said that it has fixed 154 security flaws in Java and a wide range of its other products, including one that Russian cyberespionage group Pawn Storm used to launch stealthy attacks earlier this year. The vulnerability, tracked as CVE-2015-4902, was being used by the Pawn Storm attackers to enable the execution of a malicious Java application without user interaction.
I wonder how many of these security flaw bugs would happen if we made companies actually legal responsible for the flaws in them?
Be seeing you...
... for those on Java 5/6 to get these updates.
So wonderful our Cisco routers, SAP, and Kronos require +200 exploitable holes be on all corporate computers where I get blamed and writeups for cryptolocker infections.
Needless to say our accounting department does not want to pay upgrade as they work fine.
http://saveie6.com/
Every software company would go out of business. How many non-embedded, non-life critical developers here check every mathematical operation for under or over flows? How many computer systems are hardened against a random bit flip? And how would the world react to the sudden and massive increase in unemployment as all employees of those companies lose their jobs.
It'll never happen. Consumers don't care about buggy software and non-buggy software is too difficult to code. Perfect code can fail on bad hardware too.
On top of that, WHO would be responsible, considering the deep integration of technology today? Can you even name the number of libraries in use in an application like Chrome? Check chrome://credits/ at some point! Now, is the security flaw in the library? Or the application implementing the library? Or in some interaction between two particular libraries? Or only possible on certain hardware not present in the development studio? Many exploits in the wild today require a very sophisticated arrangement of variables to become exploitable.
Large companies would simply sick their lawyers on it, and small companies or even individual maintaining open source projects would seriously take the fall for any and all security exploits, effectively crippling and eventually killing the entire computer industry. New entities in the market would be killed off while still small and would never gain the chance to mature into larger projects or companies.
Bytecode language bullshit? The majority of languages these days compile down to bytecode. And while verbose, Java is one of the best statically typed, cross-platform languages out there. The core library is massive and well documented. Cross-platform threading, cross-platform GUI, cross-platform networking, etc... No need to worry about managing a bunch of dependices and versions upgrades for the collection of libraries you'd need to replace what you'd get from the main Java library, all consistently documented, updated, and supported for you for free. A lot of the Python documentation doesn't even tell you the structure or type of what is returned. The Java docs handle all parameters, return values, and most of the edge causes like what happens when you pass in a bad value. Many 'modern' languages leave that important info out.
All these massive security holes in Java are actually in the C++ code. Part of the web start framework. Anyone bashing Java about it's security vulnerabilities is actually basing C++.
We're going to be wishing for flash to come back. HTML5, canvas only websites will be much worse.
I wonder how many of these security flaw bugs would happen if we made companies actually legal responsible for the flaws in them?
A lot fewer. Oracle fixed 154 security issues here, which means they are going through their code looking for them.
They should have done that a long time ago.
"First they came for the slanderers and i said nothing."
All OSS software would go belly up. Good job!
Bye!
It's not without precedence, software in safety critical machinery deals with the responsibility issue when someone gets hurt.
If libraries are used then it is up to the person that uses them to ensure that the library is safe to use.
The responsibility can be shifted to the library developer by them providing a document claiming that it is safe to use, otherwise it is up to the developer of the safe machinery to ensure that the functions used are safe.
Typically you don't just use a library, you use a library of a specific version with a compiler of a specific version. You also set up a test procedure for each critical software module as well as the complete software.
If you really are interested you can read ISO 13849.
When you need to make sure that software works and you can get sued into oblivion when it doesn't you don't pull in random libraries that aren't well tested. NiH means that you either have to spend more time learning how the code works than it would take writing it yourself or that you have the big black box that can come and bite you in the ass.
It is worse than that. I work for a 'security' startup that has many fortune 500s as customers. Developers ignore security reports and will mark most of the issues as false positive because they don't want to do defensive programming. They even will use years old outdated libraries, known to have security holes, to develop new features because they would have to learn the new APIs of the new versions and that would hinder their perceived development speed.
All that corporate resource and yet, won't release an Java MSI installer without paying for a support contract. Of course, support contracts for anything touching Oracle involve sums of money usually reserved for oil rich middle eastern nations.
I know one can extract the hidden MSI inside the EXE file. However, frequency of updates and the non-trivial upgrade procedure in controlled/locked-down corporate environments means a lot of businesses are more exposed than they should be.
Die Java, Die. (And I'm not say "The Java, The" in German).
Q:I was listening to a CD in Grip and it sounded horrible! What's up? A:Perhaps you are listening to country music
That's because we don't really hire software "engineers". We hire "hackers" in the literal sense of the term - people who hack and slash with crude brute force to just "Git 'R Dun!" as fast and as cheap as we can. It's like furnishing a house and all your furniture was made by the side of the road by a guy with a chain saw. No sanding, no gloss, no detail work, no mortise-and-tenon or complex joinery, just 10-penny nails and lots of splinters.
Or maybe a better analogy is particle board. Stamp on a pretty faux-woodgrain facade and ship it. Just hope it doesn't get wet.
We don't value polished quality work. As long as it's pretty and it's cheap, that's "good enough".
FTFY
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Do these same vulnerabilities exist in OpenJDK? If not, then the problems aren't with Java the programming language, but with Oracle's implementation of the JVM.
It would be like saying that bugs in Visual Studio are "problems with C".
All these massive security holes in Java are actually in the C++ code.
If you read the article, you'll see that the bug described is actually in the Java code. But carry on.
"First they came for the slanderers and i said nothing."
Well everyone complains about Adobe Flash, they cant even get by for a week without someone outing a security bug they find and Oracle manages to sit on 154 patches? for how long? well over 6 months to my knowledge. MS releases fixes every month but Oracle..get my point? Why is Oracle getting a pass?
Jack of all trades,master of none
OpenJDK is Oracle's JDK, minus a few commercial features.
Bear in mind that the 154 holes is for all Oracle products. They have a unified update release schedule which Java follows. There were actually "only" about 25 (I think) security holes fixed in the latest Java release. Of those, a lot were in components like CORBA or JAXRS, stuff that most code doesn't really need access to. And of course these only matter for sandboxing; I think only one affected server apps and that was a partial denial-of-service issue.
Unfortunately one of the problems applets have isn't so much that Java the language or design itself is insecure, but simply that the provided functionality is so enormous that bugs in relatively unimportant subsystems can end up compromising security. I think if you were to try and define an Applets2 standard these days you'd be waaaaay more aggressive with locking off access to big chunks of functionality. Applets don't need access to CORBA or SOAP or Kerberos or RMI or TIFF decoding or many other bits and pieces that Java exposes to them. You'd have way fewer vulnerabilities if mobile code had access to less privileged code.
Doubly unfortunately, the web guys don't seem to have learned this lesson. They didn't hesitate before trying to kill off Java applets back when the Java team were asleep at the wheel (they aren't any more), but since they decided everyone has to write stuff in HTML and Javascript they've been adding ... yup, massive new chunks of functionality, implemented in C++. WebGL, the P2P video chat stuff, multimedia codecs, etc. Every Chrome update contains a bazillion security fixes and it's only the huge effort put into the native code sandbox that stops this being a total disaster. Firefox doesn't even have that!