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

[Anonymous Coward]

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.

NGWS? Just so we're clear you mean .Net right? NGWS was just its early development name, it wasnt released under that name. In any case .Net also runs on ARM and has an implementation on Linux called Mono, you can end up with a platform-specific application using these frameworks by doing calls to native libraries in the same way that you can do it on Java using the JNI. Of course then you can theoretically port those native libraries to other platforms in order to support different platforms so it certainly isnt just a layer on top of win32.

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

[TheRealMindChild]

The idea was good. The implementation was poor

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

[Anonymous Coward]

so are whitelists, remember the orange book, it just helped by knowing what networks to go after

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".

Whitelists mean nothing

[Anonymous Coward]

People touting whitelists for security have a fundamental misunderstanding of security. What if your whitelisted binary is itself vulnerable?

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.

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.

Re:Whitelists mean nothing

[Anonymous Coward]

Hella Funny!

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.

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."

Still not a fix to governments/stolen keys

[Anonymous Coward]

They need a way to whitelist specific versions of specific applets. If the signing keys are stolen/signed by a different key/etc. you can still do whatever you want with the applet if your in the server or the middle.

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

[Anonymous Coward]

Everyone has already either uninstalled Java by now or disabled the web plugin.

I'm going with... citation needed.

Re:pointless

[Anonymous Coward]

Obviously you don't do enterprise IT support.

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. ;)

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

[Anonymous Coward]

You can add a time stamp to the signature using, I believe, Thawte's tscert. The benefit of this is that Java will continue (for now) to treat the jar as signed if it can prove that the cert was valid when it was signed.

By having Thawte sign the timestamp and your thumbprint Java can theoretically prove that it was signed while the cert was valid.

note: Oracle will likely break this at some point.

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.

Re:Blacklists and signing applets

[Anonymous Coward]

If you use the Timestamping feature from the jarsigner command, the TimeStamp Authority will mark when the signature took place so that it can be validated in the future.
jarsigner ... -tsa http://timestamp.verisign.com/ ...

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!

Re: Great news

[Anonymous Coward]

As is NetBeans, as is Eclipse.

This is a terrible idea. It mandates the author uses a signed Jar which uses a (paid) Trusted Certificate to whitelist. Issue being, the true threats (self-signed) are completely blocked, regardless. Have you converted a P12 to a JKS? This signing process sucks for jars. Oracle suggests the signing process is now needed for the whitelists. So ultimately, you can use a signed jar to tell java you can used other signed jar.

I propose instead Oracle fix the framework security flaws and let the little guys -- you know, the ones that can't afford the certs or the ones that aren't incorporated to pass the CA vetting process -- let them keep on keeping on rather than make them pull out their wallets and waste a week deciding this new "security feature".

The only advantage I see to this new process is it can allow 2 different JVM versions be invoked by the browser depending on how its white listed. Interested to see how many companies implement this versus just using running that one app Ina VM or through citrix. I digress.

Java 7 Update 40 sucks. I digress again.

-Tres Finocchiaro, on my buggy Nexus 4, with love.

wrong place

[Anonymous Coward]

It is the browser that needs to supply whitelist/blacklist/greylist functionality for all plugins installed in the browser.

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....

Oracle/Sun are as hopeless as Microsoft

[Anonymous Coward]

Java Applets need a whitelist because they are a "security risk"?

Everyone (including me) mocks Microsoft because ActiveX was a big security disaster.

Java was supposed to be "write once, run anywhere" with safety built in.

Sadly, Oracle/Sun have failed miserably.

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?