Java still vulnerable despite recent patches Just days after the latest fix, another Java vulnerability has emerged. Described in this Full Disclosure post, the Reflection API flaw affects all versions of Java SE 7 and, according to researcher Adam Gowdiak, “can be used to achieve a complete Java security sandbox bypass on a target system”. As always, the victim would …
Well. There are quite a lot of rather naive users out there who will always give the benefit of doubt and assume that there's no evil to be found on the Internet and that everything everyone's doing is for the good of humanity.
Java's assumption that a security dialogue is the resolution for their shortcomings in security is, well... meh.
Having said that though it certainly does seem that there are quite a number of individuals sitting on a huuuge cache of Java vulnerabilities and only releasing them a tiny bit at a time and preferably right after a major patch.
Java's assumption that a security dialogue is the resolution for their shortcomings in security is, well... meh.
+1. Breaking out the sandbox via API - biggest fail of Oracle, regardless of what muppetry the user tries to inflict apon themselves.
The sad thing, is some of us are stuck with it.
I recently uninstalled Java because I wasn't using it and I was sick of it nagging me about updates.
Then I had a support call, that required me to connect via a VPN to the network of a mining company. Their VPN solution requires one to have Java installed (and enabled in the browser), apply a registry patch to your host, then visit a particular web site they host.
When you connect, the web site downloads to your machine, a device driver, for the VPN, configures the new virtual network device, sets up IP addresses and routing tables, then firewalls off all non-VPN related traffic. All from within the web browser.
At first I couldn't get it to work. Not in Firefox (my primary browser) or IE. IE flat out refused. Firefox claimed that Kaspersky (my AV software) was "scanning running processes".
Then I read in our support docs about the Java requirement and the registry hack, so installed Java, applied the hack, rebooted. IE refused to work. IE 64-bit refused to work. Tried Firefox again, and voilà, it worked. I was then able to SSH to the affected machine and apply the fixes the client asked for.
The whole experience though left a rather sour taste in my mouth security wise.
This is one of two VPN solutions I know of, that work from within a browser. The other one also working on Linux (it prompts for your password to invoke sudo).
The fact that it's possible to make a web browser install device drivers on a host and monkey around with routing tables gives me the willies.
"The other one also working on Linux (it prompts for your password to invoke sudo)."
User privilege escalation required from an in-browser Java app on 'nix, you're kidding me right ?
WTF was the author of this shitware thinking ? They deserve to be take down a dark alley, beaten, robbed and then they just might be a little more security concious in the future.
> User privilege escalation required from an in-browser Java app on 'nix, you're kidding me right ?
I wish.
In the latter case, it was a VPN for some educational group IIRC. I didn't have any direct dealings with it, and I think it was implemented as a Firefox extension rather than as a Java applet as the one I struck yesterday was.
But yes, such abominations do exist, and are used in the industry. And yes, I do think it's blatent abuse of a web browser for such tasks. That said, it's one of the few VPN solutions that the customers I work for actually support which works on Linux, so in that regard I do say: thanks for considering us. I just wish they considered a better alternative than a flipping browser extension.
Usually its Cisco VPN bundled up in some proprietary installer that makes it nigh on impossible to extract the .pcf file to throw at vpnc, or it's an abomination like Check Point VPN (which tries to throttle local IPv4 traffic, pity it doesn't know how to throttle IPv6), or a PITA remote desktop protocol like Citrix. I think only two customers support PPTP, and two use OpenVPN (actually, in those cases, they've given us permission to supply the support gateway device, so we manage the device, Internet connection and VPN).
And yes, the fact we have to have about 10 different VPN solutions, plus our own firewall software, plus two or three virtual machine software packages (VMWare, VirtualBox and Microsoft VirtualPC), all on our workstations … that presents some unique challenges as well.
For reference, the mining company was using a solution based on F5 Networks VPN.
There might be other bits intertwined with it as well. I recall it also being flakey as hell.
"Then I had a support call, that required me to connect via a VPN to the network of a mining company. Their VPN solution requires one to have Java installed (and enabled in the browser), apply a registry patch to your host, then visit a particular web site they host."
Yep, the company I work for requires the same, and I'm forced to use if for overnight support as part of my job. No alternative gateway is available and I'm laughed at for requesting it. It's a Citrix product I believe and many companies use it. So I am forced to maintain Java on my home Windows and Linux machines or I can't connect to work, do I fail you IQ test then Chirgwin you condescending bell end? I'd look a lot more stupid if I couldn't work and couldn't pay my mortgage I'd imagine, not my fault I work for halfwits.
This is like a new version of the old phrase, "Java != JavaScript." This time it's "Java != browser." There's nothing at all wrong with having Java installed on a system. It's one of maybe a dozen execution environments that are on a typical machine. All of them are safe to have installed yet all of them can destroy your computer if told to. The problem, as usual, is with browser plugins. Plugins are a gateway to a large and complex codebase that hackers will try to exploit. Sun tried to create a Security Manager to constrain untrusted code but, as with Flash, the complexity has gotten out of control.
1) Set all plugins to "on demand" so they don't execute unless you click them.
2) Don't click them unless you know what you're running.
Enabling "Click to Run/Play/Etc" is all very well for users such as ourselves who have a better understanding of the risks which lurk around the corners of the Internet.
For your everyday Jane and Joe though all you're going to accomplish is increased left mouse button wear.
The trouble here is training your users to NOT be trigger happy and click "Yes" to every single damned prompt to run a plugin. And this is a lot easier said than done. Especially so if your target demographic are those adamant that a free Mickey Mouse Pointer is crucial to their "productivity".
It's a little bit like password policies. It almost doesn't matter at all that your IT policy prohibits staff from writing down passwords. People will still do it no matter how threatening you are. Same story with access control passes (be it key cards or 2FA tokens)... "DO NOT LEAVE IT UNATTENDED"... Yeah, right.
Nice rant, one problem.
I think the only app I ever installed that required Java was Open Office, and LibreOffice has mostly removed the requirement for that. Most of the time I (or more likely a client) need Java, it's for some web based application. Sometimes a vpn, mostly a POS accounting system. Which means on the user side of things, you're more likely to need Java FOR the browser than the safe install you developers keep talking about.
So at this point, it's not MY intelligence failure, or even my USER's intelligence failure that keeps Java on our machines.
There's nothing at all wrong with having Java installed on a system. It's one of maybe a dozen execution environments that are on a typical machine
This. The underlying message is, "executing untrusted turing complete code from random places on the internet may be hazardous for your computer", which isn't much of a surprise.
Sandboxing Java hasn't really been a viable technique for some time now. Java plugins have been disabled by default in the browsers i generally use (FF and IE) for some time now. It isn't the fault of Java that some people will simply download and run any old thing regardless of its provenance... if it isn't Java, they'll happily do the same with malicious PDFs, for example.
It doesn't help that Chirgwin misrepresents the situation by failing to distinguish between the browser and standalone environments. This vulnerability does apply to both, but the "click yes" bit is only relevant to in-browser execution, obviously.
This is a serious vulnerability (and it's very similar to a number of the others found by Gowdiak and Security Explorations, so there is little excuse for Oracle engineers to have failed to find it already, unless Oracle is understaffing the effort - which is entirely possible). Once again, it's due to the combination of privileged classes that can violate the security model, and the ability to reflect into those classes. That's a deadly combination. But it's inherently no worse than anything an attacker can do by persuading a user to run native code, or by leveraging any exploit that permits arbitrary code execution.
Getting rid of Java is committing exactly the same error Oracle is making: attacking the symptoms rather than addressing the underlying problem. Attackers have myriad ways to get uninformed and incautious users to give them access to their machines. Stick your finger in the Java hole and watch as the water comes over the top of the dike.
I had managed to unistalled Java from our office machines until about a week ago when we changed shipping companies to start using city-link, which to book and print the parcel labels require you have Java installed. Argh! its now back on our PCs until City link 'fix' their site to work without Java so we can get rid of it.
It is a shame you can set up java to only run on specific website you specifiy as we don't need Java for anything other than citylink
It is more than a decade (maybe 15 years) ago that 3rd parties started providing management software for their products using Java from within the browser. The "write once execute everywhere" attribute is very, very appealing to a manufacturer who sells a piece of kit that can plug into various OS environments, e.g. VMS, Windows, Linux, HPUX, AiX and so on. SAN manufacturers spring immediately to mind, such as EMC, and indeed Navishpere is a Java app. Managing a live SAN from the CLI is a terrifying prospect, so we choose to install Java.
So, Java exists for a lot of good and often unavoidable (for the end user) reasons, and is installed widely by people who are very definitely not morons.
Some of you guys need to get out more.
As I mention occasionally here, there is basically no bank that can be accessed without Java in this part of the world (Scandinavia), and interaction with the Danish government requires chap authentication via a national identity system. There is a large and growing class of citizen to government interactions which can no longer be executed manually - there is only the online mechanism.
Welcome to your future ...
Paris: Sadly, not my future :(
Yes, that's how it is going down over here as well (Mexico). The Servicio de Administración Tributaria (Revenue Administration Service) uses Java for filing tax reports and mostly everything related to Tax Stuff. This is because everything is done online, then signed by a private key which has had its public key signed by SAT, and thus has official recognition. And this can no longer be done offline (the tax filing).
So killing Java means I won't be able to report to the tax man. Oopsie!
This post has been deleted by its author
I'm sorry, you must be new here. You should see the general commentary from the staff about Apple.
It is a cynical, and for a lot of cases accurate, take on the way those of us who do support view the wider userbase: if we could teach them not to blindly accept everything, it would go a long way to nailing down bad-ware going places.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
