Java Update Implements Whitelists To Combat 0-Day Hacks 55
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.
Oracle are fab (Score:2, Offtopic)
Re:Oracle are fab (Score:4, Insightful)
Finally, an admission that they'll never be able to make it secure, that blacklisting everything by default is the only way forward.
Blacklists and signing applets (Score:3)
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
Re: (Score:3)
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: (Score:3)
(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 f
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:1)
Good (Score:4, Informative)
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.
Comment removed (Score:5, Insightful)
Re: (Score:2, Insightful)
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 every
Re: (Score:2, Interesting)
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 importan
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
And this is just a loose example. I'm not going to argue the merits of a platform over a bare API.
Re: (Score:2)
Format method of Win32_Volume WMI class.
Re: (Score:2)
Re: (Score:2)
Walked away from Applets long time ago (Score:1)
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: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Careful with that comment, it's an antique.
Re: (Score:2)
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:Whitelists mean nothing (Score:5, Funny)
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 (Score:4, Funny)
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 (Score:4, Insightful)
Re: (Score:2)
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 (Score:2, Insightful)
"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."
pointless (Score:2)
Re:pointless (Score:5, Insightful)
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: (Score:2)
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. ;)
Great news (Score:1)
Why only applets? (Score:2)
I would really like this feature for normal Java applications that use the JVM to get around the firewall.
Re:Why only applets? (Score:4, Insightful)
I'd recommend installing a better firewall instead.
Re: (Score:2)
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... (Score:1)
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 (Score:2)