Java Update Implements Whitelists To Combat 0-Day Hacks

kylus writes "The Register is reporting that Oracle's new Java 7 update 40 release comes complete with a new 'Deployment Rule Set' capability which allows administrators to define which particular applets and Java Web Start applications ('Rich Internet Applications') are permitted to run on a given machine. Not a complete solution for the recent trend of Java hacks that have cropped up, but good news for enterprises that have to run this in their environment." Update: 09/19 20:08 GMT by U L : There's an introduction to deploying rule sets on the Java platform group weblog too.

Comments

Oracle are fab

[hawkinspeter]

So, it has come to this.

Re:Oracle are fab

[Joce640k]

Finally, an admission that they'll never be able to make it secure, that blacklisting everything by default is the only way forward.

Re:Oracle are fab

[FlyMysticalDJ]

Obligatory xkcd: http://xkcd.com/1022/

Good

[Anonymous Coward]

This is a good thing for my company. We need java web start for only one application: the social security wage reporting "AccuWage" software. So whitelisting that is easy.

About time

[benjfowler]

Like it or not, a lot of crap line-of-business/enterprise software still uses old, hacked-together garbage applets, and they need to be supported.

There's quite a few games out there written as applets too (e.g. Minecraft, the Jin Chess Client), and speaking for myself, I want to run one or two of them without feeling like I'm holidaying in Baghdad.

Re:About time

[Joining Yet Again]

Would you mind clarifying for me what you would prefer?

Because I agree with you that Java on the desktop is horrible, but only in the sense that it doesn't properly integrate with the operating system - in that sense, web apps are even worse. DotNet/NGWS is better, but still a layer of pointlessness originally created for no other reason than MS didn't like Sun - if you're going to write platform-specific code, might as well use Win32 - then write your own cross-platform layers if needed so absolutely everything looks *native* and integrates beautifully on each target, something that every existing cross-platform library fails fucking hard at.

Once again, this is where Apple got it right: fuck web apps, because you want people to take advantage of your own platform. Hence the iOS SDK. And Android followed. This is why phones and tablets are succeeding while PCs are dying - because people are actually developing for the former, but they've given up on the latter in favour of "the web", where everything is third rate.

Re:About time

[Anonymous Coward]

DotNet/NGWS is better, but still a layer of pointlessness originally created for no other reason than MS didn't like Sun - if you're going to write platform-specific code, might as well use Win32 - then write your own cross-platform layers if needed so absolutely everything looks *native* and integrates beautifully on each target, something that every existing cross-platform library fails fucking hard at.

Creating line of of business applications whose purpose is to automate previously manual processes is much faster when utilizing Java or .NET. Entire frameworks are already at your disposal without have to reinvent something as simple as sorting an array. Suggesting that everyone just use Win32 because Windows Forms or WPF or Swing doesn't "look nice" with the rest of the OS windowing system is rather shortsighted. Things cost money to create. Time is expensive. Look and feel is not always the most important thing that those with money care about.

Once again, this is where Apple got it right: fuck web apps, because you want people to take advantage of your own platform. Hence the iOS SDK. And Android followed.

Apple certainly didn't invent mobile frameworks and development kits, so I'm not sure where you're going with this point.

This is why phones and tablets are succeeding while PCs are dying - because people are actually developing for the former, but they've given up on the latter in favour of "the web", where everything is third rate.

Succeeding at what? Consumer sales? Enterprise sales? Games? Applications? PCs are hardly dead and most of the decline can be attributed to the fact that people have no need to upgrade their PC every couple of years. I have boxes going strong after 7-8 years without any real need to upgrade. As for your final point, I don't even know what it means. You claim that people gave up on PCs and instead are developing web applications. Except...PCs can use web applications too! Web applications have a developer appeal because they can easily target a broad audience.

And just as a tip, cussing doesn't help emphasize your point. It makes you look childish and uninformed.

Re:About time

[ADRA]

Minor point, there are lots of libraries that can bring Java apps a lot more into the OS through JNI hooks, but they're used very sparingly throughout the ecosystem, and you could say the rich client PC Java eco-system is itself very small. I'd be curious to see the effect of having a Dalvik port to X86 Windows/Linux/Mac though. It'd be interesting to see if the extension of what is now a very popular platform would do for these OS's.

Re:About time

[TheRealMindChild]

.NET is a platform. Win32 is an API

Re:About time

[hairyfeet]

I agree this is a good thing and for all of us who have customers that have one or more mission critical Java based applications this should make a pretty good dent in the risk of running Java.

In the case of my customers I have several that have to send data to the main branch via a Java applet and then there are the SMBs whom are using GoToMyPC to have remote access to their work systems from home. In both cases if it weren't for that single requirement I wouldn't have Java installed on their systems but they have to have it to get their work done so this should help minimize the risk.

Re:About time

[Joining Yet Again]

From a developer viewpoint, NGWS is API layer atop Win32.

The platform agnosticity is just a legacy of the spat with Sun: it's really just for Windows on x86.

Re:About time

[TheRealMindChild]

You are over simplifying it. The platform is a whole lot more than a "layer on top of win32". It also abstracts away interfacing with drivers, enumerating devices across different buses, and a whole mess of other things that aren't even part of win32 (or NTAPI). The madness of COM is scrubbed away.

Re:About time

[Joining Yet Again]

What driver interfacing can I do with NGWS that I can't do with native user-mode code, please? And when would I actually want to do it?

Re:About time

[TheRealMindChild]

Format a disk. And before you say it, SURE you could write code to interface with SCSI and ATA and implement FAT and NTFS and whatever else in user mode code. The point of a platform is you see a disk and you say format with a couple of flags.

And this is just a loose example. I'm not going to argue the merits of a platform over a bare API.

Re:About time

[Joining Yet Again]

Format method of Win32_Volume WMI class.

Re:About time

[TheRealMindChild]

That isn't win32, friend

Walked away from Applets long time ago

[Anonymous Coward]

I'm so glad back in 2001 when I worked for a company that was considering using Java applets that we stayed away from them. They load slow anyway and just cause headaches with compatible Java versions installed on the client and all.

Re:Walked away from Applets long time ago

[benjfowler]

"Write once, test everywhere"

Re:Walked away from Applets long time ago

[Atzanteol]

Careful with that comment, it's an antique.

Re:Walked away from Applets long time ago

[ADRA]

Assuming the sandbox can be trusted to do the right thing, Applets are pretty trivial to deal with fixed requirements for JVM versions these days without causing a world of hurt for end users.

Re:Walked away from Applets long time ago

[petermgreen]

Java applets have had a couple of issues over the years.

In the early days the problem was incompatible variants. MS had their own JVM which was in very widespread use and only supported a very old version of java.

More recently the problem has been that the security design just isn't standing up to the threat level on the modern internet. For "untrusted" applets Java was designed arround the idea of designing a full-featured API and then trying to lock it down to run untrusted code (usually but not always in the context of running applets) but cracks in that lockdown have appeared repeately. For "trusted" applets users don't take the security warning that pops up before running them anywhere near seriously enough.

Still for many years java applets were the best way of achiving some things. Java applets allow you to do things like VNC clients, IRC clients and so-on without having to have a resources hungry "translation server".

Re:Whitelists mean nothing

[Joining Yet Again]

What if you're wearing a condom but your one night stand has a knife? Did you even think that through?

Re:Whitelists mean nothing

[kylus]

As I said at the end of the summary, this really isn't a complete solution and you're right about a whitelisted applet/RIA being vulnerable. However this is a good piece of 'defense in depth' to prevent random Java crap from executing without authorization if (when) another bug crops and is somehow exploited. If the stuff you're whitelisting has problems, you need to revisit your coding quality checks, or talk to whatever vendor is supplying it to you.

Statement from Oracle

[Anonymous Coward]

"We give up. We're too incompetent to fix the bugs, so we'll just foist a huge inconvenience on our customers who are locked in to our platform."

Re:Whitelists mean nothing

[JustOK]

My night stand doesn't have a knife. Toe nail clippers, phone charger, box of kleenex, clock radio, lamp: those are the things my night stand has.

pointless

[slashmydots]

I don't see the point in a feature like this. Everyone has already either uninstalled Java by now or disabled the web plugin. Me turning it back on whenever a page legitimately needs to run a Java App is the ultimate whitelist.

Re:pointless

[h4rr4r]

No everyone has not. There are a great many enterprise apps that companies rely on that need this. Normal users will not know to turn it on, nor to turn it off.

Re:pointless

[Gravis Zero]

No everyone has not. There are a great many enterprise apps that companies rely on that need this. Normal users will not know to turn it on, nor to turn it off.

i wouldn't go so far as to call them great. ;)

Re:Whitelists mean nothing

[TheCarp]

No, you have a misunderstanding. Your whitelisted binary being vulnerable is a problem, but, its not the same problem. I think the correct answer is, you whitelist AND fix the app.

Blacklists and signing applets

[Anonymous Brave Guy]

blacklisting everything by default is the only way forward.

That's fine as long as I, as the user and sometimes developer of applets, can change that default when I want to.

Today I installed Java 7 update 40 and Firefox 24, and for the first time in several weeks I can test our web application running from a local disk without Firefox refusing to even load it, regardless of any lowering of security settings. I suspect this was actually Firefox's fault, because the same application worked fine, applet and all, in other browsers on the same system, but in any case it was a pain in the backside for testing.

However, we don't sign our applications, and for a good reason: they will ultimately be running on embedded systems where there is no way to update them, and the signing certificates you can buy from established CAs are all prohibitively time-limited. I notice that with this release of Java, the scary warning message has been changed to say that in a future release this will be completely blocked.

If that refers only to running from a local system without needing to fire up a web server, that will be an inconvenience for testing again, and helping no-one here. It's not as if an applet we just compiled from our own code is a security risk.

However, if it refers to blocking any unsigned applets, it's going to instantly and permanently break numerous existing installations on embedded systems. Applets are used more than a lot of people realise, and one significant use case is web-based control panels for network-accessible devices. Those devices probably have a working lifetime of many years and if they all stop working overnight because Oracle broke Java, it's not going to go down well.

Re:Blacklists and signing applets

[Joce640k]

However, if it refers to blocking any unsigned applets ....

Let's hope so.

it's not going to go down well.

Why? Is clicking 'allow' the first time you visit a page too much effort for you?

(assuming that's what it does)

I imagine most people can just whitelist one or two domains then everything will be business as usual (except the entire world-wide-web won't be a minefield any more...)

Re:Blacklists and signing applets

[Anonymous Brave Guy]

(assuming that's what it does)

Unfortunately, it isn't.

Recent Java updates, for around the past year or so, have been increasingly draconian in their security measures. We are now reaching the point where you can't run code that you know is perfectly safe, in ways that have worked for years, even if you are willing to turn down the security settings and accept any associated risk. Much of this is Java's fault, although well-intentioned but buggy browser updates have also broken essential functionality at various points within that time frame.

Security that actually stops you doing your job isn't an improvement, it's just broken.

Also, the idea that merely signing an applet significantly improves the safety of running it is rather strange. Which is really safer to run, an applet I just compiled right there on my own system from our own code using a tried-and-tested build process, or an applet downloaded from a web site I never visited before that could be anything but is signed with a certificate that anyone with a bit of cash and a bit of time can easily obtain?

Re:Blacklists and signing applets

[aled]

Recent Java updates, for around the past year or so, have been increasingly draconian in their security measures.

Well, considering that Oracle has been consistently bashed here in Slashdot and other sites because of the security problems with applets and client side Java I would think that is very reasonable for them to increased greatly security.

Re:Blacklists and signing applets

[Anonymous Brave Guy]

As I wrote before:

Security that actually stops you doing your job isn't an improvement, it's just broken.

Also, a lot of the Java bashing that goes on here on Slashdot is little better than trolling. Take a look at how many security issues quietly get fixed in your favourite OSS browser every few weeks. Take a look at any popular browser plug-in. Java plug-ins do have a long and unimpressive history of security vulnerabilities, but they're hardly alone.

The thing that really annoys me about the current trend with Java is that the supposedly increased security is mostly a work of fiction anyway. Signing your applet the way they want you to doesn't prove anything about its behaviour or trustworthiness. All it proves is that you got hold of a certificate from some recognised CA and figured out how to use it, and any halfway competent malware author could do that with a bit of money and a bit of time. Meanwhile, the experience for legitimate users running legitimate applets is becoming more and more hostile.

Great news

[InTheSwiss]

As someone who is just getting back into Java development the security issue of the past few years have had me a little worried. This is a great step in the right direction. Kudos to Oracle. I hope that the work they are doing on the browser plugins in Java 8 improves on this. On a kind of related note; IntelliJ IDEA is a freaking sweet IDE! It isn't quite up there with Visual Studio but it makes working with Java much nicer than it was a decade ago!

Why only applets?

[Hentes]

I would really like this feature for normal Java applications that use the JVM to get around the firewall.

Re:Why only applets?

[swilver]

I'd recommend installing a better firewall instead.

Re:Why only applets?

[dkf]

I would really like this feature for normal Java applications that use the JVM to get around the firewall.

What? That doesn't make any sense, not unless you're talking about basing whether code can get through the firewall on the path to the executable or something equally silly (given the existence of the JVM, Python, Ruby, Perl, ...).

Just got done installing 7U39...

[kmg90]

Is oracle releasing updates on a bi-daily basis?! I could have sworn I was installing update 25 last month!

Note: I have no problems with having security exploits and vulnerabilities being patched, it's just at some point it would be easier on the end user to consolidate updates....

What the hell

[CTachyon]

Package your ruleset.xml into DeploymentRuleSet.jar

Packaging your ruleset allows the desktop administrator to apply cryptographic signatures [emphasis mine] and prevent users from overriding your policy. This requires usage of a trusted signing certificate. The easiest route to get a signature is to buy one from a certificate authority like Symantec/Verisign, Comodo, GoDaddy, or any other; [...]. The default certificate authority list contains about 80 authorities from which you may purchase a signing certificate [emphasis mine].

-- Introducing Deployment Rule Sets, Java Platform Group blog

Why in the name of the everliving fuck would anyone think this step was a good idea? The file is already located in a directory that can only be written by root (or Administrator, as OS appropriate). Why require a signature? This adds zero security. If you have root on the machine, you can add a self-signed CA to the trusted CA list anyway. Do they have a kickback arrangement with Verisign or something?