Slashdot Mirror
Oracle Releases Massive Security Update
wiredmikey writes Oracle has pushed out a massive security update, including critical fixes for Java SE and the Oracle Sun Systems Products Suite. Overall, the update contains nearly 170 new security vulnerability fixes, including 36 for Oracle Fusion Middleware. Twenty-eight of these may be remotely exploitable without authentication and can possibly be exploited over a network without the need for a username and password.
There is still no way of authenticating Java downloads? Either a download through HTTPS or a hash fingerprint of the file, accessible via HTTPS? This used to exist up until ~2 years ago, but now it is all insecure (the download can include drive-by malware).
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
As a security remediation specialist, I'll look forward to seeing the Nessus scan spreadsheet that identifies the systems that has a Java vulnerability that wasn't automatically updated. Last time I only had 3,600 systems to fix over a six week period. Thanks, Oracle!
Those languages strongly encourage you to produce your own security holes.
Looking forward to when I migrate the last Solaris 10 server over to Solaris 11 (or 12?) and get a real package manager.
And what percentage of C/C++ code is well written?
Or, to put it another way, is there any evidence that Java applications are LESS secure, on average, than C/C++ applications?
The world's burning. Moped Jesus spotted on I50. Details at 11.
This [massive] update will surely provide fertile playground for those hacker boys.
I can almost guarantee that we will be asking ourselves whether Oracle did anything useful with this update within a year.
"Twenty-eight of these may be remotely exploitable without authentication and can possibly be exploited over a network without the need for a username and password."
Which?
The original bugs, or the new security fixes?
I mean, when you qualify your comparisons by using ambiguous, ill-defined phrases like "well written," you can say anything. Novels are less interesting than a well written comic. Rules are less useful than a well written law.
Java is generally going to require less effort to port unless you're using platform-specific libraries, and that's easy to avoid since so much is included in the JDK.
As for the security of that code, everything may be within your control in C, but that doesn't come without some cost -- namely requiring deep knowledge of everything that's within your control to avoid creating your own security holes. And if you're using third party libraries (which is typical) then you're sacrificing some degree of control anyway. This is especially true if they're closed-source libraries, but even with open source, many people just trust that someone else has reviewed the code.
https://www.eff.org/https-everywhere
I wonder what percent of typical security flaws are caused by language-specific features versus poor design decisions and human error (such as passing the wrong variable). I suspect most are the latter.
Table-ized A.I.
Even trying to go back to version 7u71 doesn't work now. Never had java problems until this update. YMMV.
How many unauthenticated remote exploits in a HTTP stack does it take to lose a customer?
Never understood how Oracle is allowed to continue to operate like this. The only thing worse than a multi-billion dollar software company failing to exercise any discipline over their systems unauthenticated attack surface is length of time they must have sat on all of these exploits just so they could package it up and release all at once.
Java isn't at all immune to the 3rd party library issue and in fact the Java world seems to have it far worse when you start developing complex applications.
What I find even more appalling is that fact projects that use maven seem to want to hoover down half of the internet, and you have to trust that the bundles/jars that it is pulling down are all of decent quality, and that the repository has not in fact been compromised.
I don't know about the rest of you... but I, for one, am very happy that Oracle's products are now Massively Secure.
Well, letsee, I'm a developer, I hate Java programming, I don't write Java, but I need to have it installed. Why?
- Android developers need Java, even if they don't write Java. Writing a hybrid app using, say, PhoneGap/Cordova, Rhodes, Titanium, etc? You need Java.
- Backup with CrashPlan? You need Java. CrashPlan is not alone here. Many similar programs need Java.
- Many other disk/file type utilities use Java. Pretty much any of those nifty applications that show you what's using all your disk space using graphics.
- I have a home automation controller (isy99i). It has a web UI, but that still needs Java. (You can use it in a browser or on desktop, but either way the UI uses Java.)
- Again for developers, way too many build processes that aren't Java-based seem to throw in one little part of the build process that uses Java. (That is, say, they use rake, Grunt, etc. I guess they had one developer who was in-disposable and that just couldn't go along with the program.
- Developer using Eclipse IDE? Or many other development environments that use a bundled Eclipse? You need Java. (I try to avoid these if at all possible, but sometimes it is unavoidable.
Do you see the scary thing here? Java is used by a lot of software developers, even if they don't program in Java. It's also used for a lot of backup and file utilities. Perfect vectors for mischief.
Oracle releases a Java SE update to plug security vulnerabilities, but the installer still prompts me to install the 'Ask Search App' by default.
Does anyone see a conflict of interest here?
Oracle seem to be the one organization that doesn't appear to be getting better with security, if anything they have deteriorated over the last few years. wonder what it will take for them to take security seriously.
A large percentage works just fine even with holes, and with greater performance and less overhead. The supposed claim to fame for java was that, while slower and resource intensive, it prevented programmers from writing exploitable code. Today, we know it's possible to make a shitpile with any tool, leaving java and other runtimes to sacrifice much of the potential for lean, high performance software for small gains in security (the latter with a growing list of caveats). I'm not a fan of such mediocrity but it has become the norm these days. It also doesn't help that java comes with a browser plugin that opens a complete runtime environment to drivebys. Microsoft abandoned activex for this reason.
We buy the Solaris 9 patch support. The changes for this cycle are 1) TimeZone files updated, 2) Fix to zip and 3) Java fixes
The last kernel patch which required a reboot was 122300-68 from June 2013.
My Solaris 11.2 box gets rebooted way too often to replace other production servers and its better than Sol 10.
Someone at Oracle should learn the difference between an operating system and an operating environment and making sure the OS is rock solid.
Those languages strongly encourage you to produce your own security holes.
This is sage... No language can protect from a stupid programmer.
Of interest the security model and features in Java as far as I can tell has foundational .... and parts of the security
problems. The sandbox is not as well built as it might be
model are unverified and ill understood.
It is a notable language. It is not magically secure...
The moderately recent enhancements to the VM to permit other languages to use the VM are interesting.
Oracle has used Java for a long time and before they picked off Sun depended on a very old
and outdated version of Java to run many Oracle tools in a browser. This left such a bad
impression on me that I have been unwilling to look and see if it is still necessary to use Java 4.5
or whatever it was...
In the intervening years I would hope that Oracle fixed this now that they own both parts.
Not owning a dependency is like having a pebble in your shoe, painful and crippling.
Being an optimist I hope this was the reason for getting Sun... I hope they acted on it.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
Then have a closer look.
A large percentage works just fine even with holes, and with greater performance and less overhead.
You need benchmarks to prove such blanket statements. In my experience, Java code usually isn't far from C++ performance and it's actually faster when we're talking about high level "glue" code. It vastly outperforms C in string handling, because C's standard string routines are awful not only to the programmer, but to the processor, too. And then again, for maximum performance there's FORTRAN.
Today, we know it's possible to make a shitpile with any tool, leaving java and other runtimes to sacrifice much of the potential for lean, high performance software for small gains in security (the latter with a growing list of caveats).
Do you know any example of stack smashing, buffer overflows, invalid pointer dereference, malloc failures, code overwriting done by a program written in pure Java? They're the stuff that hackers love. They happen automatically in C: any code you write causes them by default, and you need to be very clever, to have complete information about the machine state after every instruction (which is usually impossible), to have platform-specific tool support (relro, noexecstack, ASLR, ...) in order to avoid or prevent them. In Java, they just don't happen, barring bugs in the JVM, which are akin to bugs in the runtime library of any compiled language of your choice. If this isn't an improvement...
It also doesn't help that java comes with a browser plugin that opens a complete runtime environment to drivebys. Microsoft abandoned activex for this reason.
To be honest, the runtime environment for applets was supposed to be restricted (it's not the same runtime environment that Java applications see). It's the same mechanism that post-HTML5 Javascript has, except that at least we can disable (or better delete) the awful Java plugin, while we can't do the same for the browsers' Javascript support.
Still wondering if they will be able to publicly release their java MSI package.
I know they have one, because I see it on the downloads and support page for JDE E1. However I don't have access to the inner working of our corporate licence and work out if we are eligible to deploy it.
It would be possible just to download the MSI and deploy it. But Oracle do keep auditing us. So, better safe than sorry. (For various values of the word 'safe').
Q:I was listening to a CD in Grip and it sounded horrible! What's up? A:Perhaps you are listening to country music
Obviously, the efficiency of the C lib functions will vary by hardware and by author competence, but here's no way virtualized code could run faster and with less cpu and ram overhead than well written (or compiler generated) native code on given hardware.
An interesting bench done with 7 year old software and hardware (perhaps things are better today?).
http://zi.fi/shootout/
While it's gotten a lot better since the 90s, ~35-50% slower is still significant (assuming you discount the 'compiled away' situations). The strings bench is near the bottom. Unfortunately, he did not measure memory footprint or calling overhead. This is too bad because this is another area where managed runtimes come up short.
For example, the installer for freespace2 SCP is java based, and it takes 50MB of ram on startup, and grows from there as it downloads files from the network. I use tinywall on my windows box, and currently that's sitting at over 100 MB..for something that just inserts rules into the system firewall based on PID/name. That's nuts for such simple programs.
Most managed programs call out to C libraries through shims when speed is needed because the vm carries too much overhead, even when the executable is targeted for specific hardware. For example, modern game engines do this a lot. The fact that virtualized logic can touch unmanaged space breaks the security model, making it pointless to expect any additional security from the virtualization.
stack smashing, buffer overflows, invalid pointer dereference, malloc failures, code overwriting done by a program written in pure Java?
Properly written C does not cause those. Buggy C certainly does, just like buggy vms. The fact that oracle has been patching java exploits for years suggests its security isn't much better than a typical unmanaged C++ program at least as far as the user's concerned.
I mentioned the UI/system integration before. For me this is reason enough to avoid managed/interpreted runtime programs unless I have no choice. The shimming and overhead is prone to breakage and there're usually native alternatives that behave better.
Seriously, what's the big news here?
They have been pushing out bundled security patches every quarter for years with their Critical Patch Update program. This is just another CPU.
Java protects against some of the common screwups that lead to security holes in C (and to a lesser extent C++) programs. It simply won't let you do things like read/write beyond the end/before the start of an array, perform an unprotected typecast between two object types or use memory that you have already freed. However there are many other classes of security hole it doesn't help with.
Java sees lots of security patches for a couple of reasons
1: Java provides sandboxing features intended to allow safe running of untrusted code. Unfortunately such sandboxes seem to be very difficult to get right (whether it's java applets, flash or javascript in browsers).
2: Java provides a massive standard library. It's virtually an OS within an OS and that means lots of code to be potentially vulnerable (especially in light of point 1)
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You're comparing apples and oranges. The "remotely exploitable bugs" in this Java update, like all the others, are assuming you download and run malicious code in the sandbox. GCC and glibc don't have protecting you from malicious code as a goal, in fact Linux typically requires all software to be installed as root no matter what. Obviously if you never even try, you cannot fail.
The interesting story here is not so much that sandboxes have holes (look at the Chrome release notes to see how many security holes are fixed in every update), but rather than the sandbox makers seem to be currently outrunning the sandbox breakers. In 2014 Java had security holes, but no zero days at all - all the exploits were found by whitehat auditors. Same thing for Chrome, people found bugs but they were found by the good guys.
I'm not sure if this means the industry is finally turning a corner on sandboxing of mobile code or not, but it's an interesting trend.
in fact Linux typically requires all software to be installed as root no matter what
Technically yes, running "make install", using a package manager or installing an rpm/deb almost certainly requires root/sudo. However, there is nothing stopping you from keeping it all within your home directory (provided the /home filesystem has space and isn't set to noexec), many cases only requiring a wrapper script to modify LD_LIBRARY_PATH. A good example of a complex program which works this way would be apache directory studio, you just untar and launch the executable.