I wish to God that Oracle would simply deprecate and discontinue browser-side Java applet support.
Whenever people see a headline like "Java Vulnerability Found!", it is virtually always referring to the client-side applet plugin. Yet 99% of readers don't understand that, and think that Java is insecure in general.
Whenever people see snark about Java installing the "Ask.com Toolbar", it is referring to the client-side JRE installer (i.e. applet plugin). That's virtually irrelevant to developers, because we install the full SDK which contains no crapware and never has. Yet 99% of readers don't understand that, and think that being a Java developer means dodging malware with every upgrade.
Java applets are basically the non-Microsoft business world's answer to ActiveX. A dead 1990's technology that no one has cared about in 15 years or more, which only still exists to support backwards-compatibility for some horrible crusty shops still running on XP or even NT/2000. No contemporary Java developer gives a fuck about applets, and by "contemporary" I mean "any greenfield development done since 9/11". However, we're all sick to death of having to defend our ecosystem against constant FUD, due to this horrible piece of obsolete legacy cruft.
I need java support in the Browser. Have you ever tried to use it? You have to do no less then 10 clicks with lots of warnings and restart the browser in order to activate it, and that's only for one site. And you have to repeat that for every website that uses java-applets.
It's a way easier to download a binary and execute that.
It's dead for the end-user for every meaningful definition of "dead".
Also ActiveX was the MS answer to Java, not the other way round.
That's why this might be a noble thing for Oracle to do. Institutions around the world are harming their users using this tool, and it's possible Oracle could encourage them to stop doing that. (Although frankly just mentioning the possibility that an action might be the right thing to do, seems to make it less likely that Oracle would do it.)
You must be either exaggerating or not up to date (not aware that not every applet is automatically run). I don't think anybody is getting harmed. What do you think a realistic attack scenario using Java applets looks like? You'll have to break RSA, or how are you going to fool the browser plugin to run your exploit?
GGP comment observed that many people can't avoid using Java applets. Others have observed that the Java people have to use for applets is often quite old, so it is perhaps as old as the Java I used the last time I had to use Java applets. I'm sure that very few of us are "up to date"; that's kind of the point. Perhaps there are strange applet fetishists who keep their Java package installs at the bleeding edge of postmodern Java applet specialness. Even so, forcing normal people to use Java applets is harming your users, because normal people turn it off.
As recently as last year I've seen browser apps that require Java 1.3. As in they won't work with Java 1.4+. Until browsers kick Java out, Java applets aren't going anywhere.
"I can't think of any applications that couldn't be made with JS and html5, so institutions must have no reason to use Java besides wanting to harm their users"
The only way to file a (mandatory under penalty of huge fines) monthly tax report for a business here where I live is a web service that requires Java (or ActiveX) to do a digital signature for filed documents. There is currently no alternative (JavaScript APIs for that do not exist). Same goes for all other digital banking - requests have to be cryptographically signed and Java is pretty much the only widely portable way to do it.
Is that "end-user" enough for you? All busness owners in the country and all other general population doing eGovernment?
These governments and institutions should be called to task, PMs/ministers/MPs impeached if need be. Their negligence or refusal to act on this matter is a threat to national security. Literally.
I don't understand - there are end-users in those institutions using java applets. They have to use java applets because their institutions mandate their use for anything from bug tracking software (yes really, I've seen it with my own eyes) to expenses software.
Java-applets in the internet are not used anymore as i explained. And if quite a few poeple use it in their intranets they don't care particular for a 0day. If their intranet is used to deploy these, everything is already lost.
Even if the webbrowser that displays the intranet applets is used to surf the internet it's not a attac surface as you have to whitelist every site that's able to use applets.
Since the Javascript NemID client was introduced last year, most users don't need Java anymore.
That's for OTP though, users with tokens or keyfile have to use the OpenSign applet still. Haven't seen any stats, but OpenSign usage is probably pretty small compared to standard NemID/OTP.
One of those crufty little shops is ADP, one of the biggest payroll processors around. I hate that I have to use their applet crapstack, but it's not so simple to just turn it off.
Very true, but Step #1 is to declare it deprecated.
Look, Microsoft is still struggling to retire Windows XP, a 14-year old operating system that was end-of-life'd over six years ago. However, at least they've been TRYING... and sending clear signals that support won't extend indefinitely.
Oracle, however, hasn't even begun the official process of winding down applet support. So why should ADP, or any other "captive-audience", "bare-minimum" crapshop even consider putting migration plans on their long-term timeline?
Just say it's deprecated. You don't even have to commit to a fixed end-of-life date yet. Just start the ball rolling with a signal that remaining on applets into the 2030's won't be a viable long-term vision. It might well take a decade or more to fully wind it down, but the first step is simply signaling your intention to eventually do so.
At this point, it's hard to argue that benefit of perpetual applet support isn't outweighed by the harm that it inflicts on public mindshare for the rest of your platform. At least start signalling that this cruft is going away eventually, to change the narrative about Java overall being cruft in general.
As I just indicated above, they should do so because the support revenue stemming from applets is surely outweighed by the damage to their brand overall.
However, given that Oracle still pushes the Ask.com toolbar in their consumer-facing installer, it does seem clear that they are not yet concerned about that calculus.
Perhaps if Microsoft's open-source, cross-platform changes to .NET makes them a more significant threat in a few years... or if maybe some newer emerging non-JVM language starts to gain traction in the enterprise... then Oracle will be pressed to drop its complacency. That is indeed a very slow-moving world, but Oracle practically radiates a "We Couldn't Care Less" vibe, and that would seem to make it vulnerable to disruption at some point.
>they should do so because the support revenue stemming from applets is surely outweighed by the damage to their brand overall.
'Surely'?
If that were the case, why wouldn't Oracle have already done so?
Why don't you assume that Oracle has already run the numbers on how much they collect from enterprise contracts to support all manner of legacy technologies (including applets) and choose to exploit it? A good portion of Oracle exists just to service that revenue stream.
You want them to also drop another revenue stream (Ask/Yahoo co-branding) because of the "damage to their brand overall" from a co-branded installer? Sounds like a good way to give Larry a chuckle.
I doubt many who care about the terrible JRE installer would suddenly start sending cash Oracle's way because they removed the Ask/Yahoo bundle.
Because of the shame and brand damage of making such a terrible product? And because people who want to call themselves professional engineers have a moral obligation not to knowingly fuck things up for their users too badly?
A car company shouldn't sell a car with defective brakes, even if the defect was great for replacement airbag sales.
> Because of the shame and brand damage of making such a terrible product?
From the article: this is the first Java zero day in two years.
Now how many other products we use all the time have had no zero days found for two years? Chrome? Windows? No.
What's more, it's not totally clear that this is even a problem in Java itself, seeing as it apparently relies on a Windows-specific common controls library exploit? There aren't enough details in the report to say, but it seems likely that this is somehow (ab)using AWT to trigger a bug in Microsoft's code.
I agree. If anything, owning Java is a brand improvement, based on my (admittedly limited) experience with other Oracle products. But that's just my personal opinion.
Look at Microsoft receiving multi million dollar payments for continued XP support, there's the potential for more support revenue by announcing the intention to EOL.
One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive.
After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop).
The most important requirement is to use the DB file installed in the user's hard drive (always same directory, no way to change it): can't generate new ones because the gov't program stores some cryptic arcane data in it, and even though we could reverse engineer it, we wouldn't be legally covered if we sent the wrong cryptic data.
Second requirement is: users are ignorant, don't know how to save files and how to navigate directory trees, 'computers = magic' to them.
Have them download and run a desktop program. You could even write it in Java and also bundle a jre within an exe for actually better overall experience for windows users.
> Have them download and run a desktop program. You could even write it in Java and also bundle a jre within an exe for actually better overall experience for windows users.
Yeah, it would work. Could even have used Java Web Start.
The webapp would have to be developed as a web service with a desktop client (and maybe a web client as well), as the data created by different users, with different roles, and in different office buildings, had to be shared.
Is it OK to bundle the JRE in a closed-source program, though?
Yeap. It's preferred to vendor a JRE (non-system JRE) inside your app (which is basically just extracting it to some dir you always control), which doesn't conflict with whatever else is on the box (no registry settings, /etc/profile or common locations like /usr/some/unix/path/to/system/jre ), and auto-update your app which includes updating the JRE. This is how to deploy a supportable app, which reduce support tickets about "you broke our apps, our IT department is going to call our VPs and is going to call your VPs" and pre-sales issues like "we can't buy this because we can't change JRE versions."
>One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive...After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop)....
> How would you address this situation?
Well, first I would sign up for a github account. You know steps two and three.
I just noticed this got downvoted. What I meant is that in a situation like that it's really time to polish your github and linkedin, so you can quickly get a different job. If it's a fragile legacy system with Access 1.0 (!) and a bunch of external requirements you aren't allowed to touch, how much of a change can you make?
Killing it might be hard as long as companies like Cisco base their products on it. We tried a dozen of teleconferencing programs and none was able to beat Cisco Webex Java applet. Ugly? Maybe. Slow to start up? Indeed. But just works on anything (Windows/Max/Linux/Android etc.) and doesn't spin up the fans in my laptop to 100% like Google Hangout does.
Nope, Webex it doesn't work on:
* Android (tested 4.4.4, app opens chrome on a page that asks to install the same app, when opening with firefox it says that it is not supported) - why app would open a browser is beyond me
* Linux 64bit - screen shared by others is not visible
A _lot_ of really shitty "web interfaces" which are actively supported/created/updated for enterprise products use java applets. They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).
Lots of companies and lots of developers give lots of fucks about Java web UIs. Because Java programmers are commodity programmers. Everyone knows the language and inexperienced programmers can be productive in it without any great risks. (Not to say that there should be any strong association between knowledge and usage of JVM tech and competence, it's just anything that reaches that depth of adoption is bound to have lots of ... mediocrity)
>> They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).
Including web or just client side? If the same UI's that you consider terrible on the JVM were ported to say, well pick any language/platform and ported exactly but using your preferred language and platform features; would the interfaces now be better since they are implemented on your desired language/platform?
Um, some shops still running on XP have a good reason to do so--generally some piece of hardware that the vendor never found worth the time to update the device driver.
The fact that Vista and later broke device driver compatibility with XP is THE single thing preventing those of us who would like to upgrade to a newer OS from doing so.
Microsoft thought that breaking compatibility with things like Visual Basic 6 and XP device drivers would force people to upgrade. Instead, it caused people to put a stake into the ground and never upgrade ever again.
Ugh, how I envy your reason. Unfortunately, I work in higher education, where things move at an agonizing pace. As such, I end up having to use a lot of Java applets just for the sake of compatibility with the framework the college has been using for over a decade (Adobe ColdFusion). So, as much as I'd love to kill Java applets, I still rely on them. Sadly, this is a case where culture will have to change before tech will get its chance.
You're probably right... at the very least, they should re-brand the applet container because it does create massive amounts of FUD.
As others have noted this is really a Windows issue, not an inherent flaw in Java. And as you note it seems to be a problem in the applet plugin, not necessarily the standalone J2SE runtime. It should be possible/obvious/necessary to install the two separately on Windows.
With the advent of things like NaCl, Emscripten, and WebAssembly these things should not be necessary anymore. Undoubtedly these new technologies will be able to properly sandbox untrusted obfuscated compiled code perfectly and should immediately supplant things like applets.
You can't. Plenty of expensive software runs a Java UI, browser hosted. Though, they often need older JVM versions as they don't run with the latest update.
I don't think Java is enabled by default in any install, is it? So what's the risk?
It usually is, at least that's been my experience on Windows. I have to usually disable it myself after installing the JRE, because I know where that game is going (usually ends up being disabled by Firefox automatically eventually).
my bank in brazil still uses a java applet for "security measures". i complained about a thousand times but they still think it's more secure to use a java applet than using nothing.
It's absurd that the official Java runtime for Windows comes with crapware and spyware ... Ohh, your program requires me to install Java? Then I think I'll pass.
Just include the runtime (around 140mb) and your customers won't know or care that they are using Java!
Reporting says this is for Java in the browser, on Windows, and the target must visit a malicious URL.
"[Emails] contained links to malicious domains hosting the Java exploit (JAVA_DLOADR.EFD). The exploit is designed to deliver a Trojan dropper (TROJ_DROPPR.CXC) that drops a payload detected as SPY_FAKEMS.C to the “login user” folder."
"The security firm noted that the vulnerability affects the latest version of Java, 1.8.0.45, but older versions such as 1.6 and 1.7 are not impacted."
"Disabling Java in your preferred browser is for now is a better option. Use a secondary browser with Java enabled to view sites you absolutely must visit and which require it."
"The attack leverages a three-year-old vulnerability in Microsoft Windows Common Controls CVE-2012-015."
I lodge my sales tax via a java applet, recently I straight up could not get the applet to run on any of my machines after they went down for an update.
I called them up, and their answer was basically: "We can send you a paper form to submit but it will take x days to do that, you will be charged late fees and interest for not lodging on time"
This story is odd. Perhaps it is pure click-bait? Why would an attack that depends on a vulnerability Microsoft fixed three years ago be successful or even attempted today?? And...if someone were running a machine without this MS patch, and presumably also without a browser that makes you perform handstands while singing "There's no business like show business" before it will run Java, then wouldn't they also be vulnerable to hundreds of other issues fixed in the past few years??
I think he's implying something that would be remotely exploitable on a server running the JVM for a service with an open socket. Which is very common. Also the the File API could potentially be exploitable (if a vulnerability exist) remotely also if for example it was used for file uploads or something. Seems non-trivial but I can see how it could happen.
True, if there was a vulnerability where reading a byte stream could trigger a JVM exploit, that is exploitable. But that would be a really weird bug, since the JVM isn't going to be the one parsing a byte stream.
Most JVM methods can require permissions because it provides built-in POLA ACLs (security policies). The default would likely be to deny network access and file io. It's more likely that an app itself contains vulnerabilities &| unnecessary weaknesses due to ease of misconfiguration because of the pervasive lack of full-stack implications, grokable and auditable security policies.
For instance, Java application servers often have the capability to implement policies per application - so you can run the app server as a privileged user but do things like restrict access to parts of the file system, opening network sockets, using JNI, etc. Essentially this is the same mechanism that applets use to sandbox code. So any exploit that could circumvent this could have an effect outside of the browser, in theory.
> A buffer overflow vulnerability in the Java Runtime Environment with processing PNG images may allow an untrusted Java Web Start application to escalate privileges.
Java Web Start: In computing, Java Web Start (also known as JavaWS, javaws or JAWS) is a framework developed by Sun Microsystems (now Oracle) that allows users to start application software for the Java Platform directly from the Internet using a web browser.
That was the biggest attack vector but not the only one. Many of these image exploits also applied to e.g. pure server-side software that happened to use the java standard library to process user-submitted images.
* Bug in the default XML parsing library that exposes local files, existence of local files, or even allows a user-supplied XML to open a socket to a remote server?
* Vulnerability in SecurityManager that allows a sandboxed jar more privileges than it is supposed to have?
* Allowing a default RMI-JMX configuration to provide an attack vector to authenticated clients whereby they can upload arbitrary code that executes outside of a SecurityManager?
My guess would be that Java continues to run an unpatched copy of MSCOMCTL.OCX. If you look at the CVE-2012-0158 patches[0] you'll notice that Microsoft had to patch a lot of software individually, I guess Java just was never fixed.
So it is a Java issue only in the sense that Oracle needs to update it. Obviously the original "bad code" was from Microsoft.
Isn't the "Malicious Software Removal Tool" from Microsoft supposed to scan for such things? Obviously it isn't a full-fledged virus scanner, but I would expect scanning the system for outdated DLLs and such to be well within its reach.
JVM & CLR runtimes probably account for 75% of all enterprise backend apps running on server gear in production right now. Both have been beaten on for so long that they're both fairly reliable, which is not to say either bug free (reliable or secure), resource efficient or maximally productive, just more usable in production on average.
On the client side (browser-land), JavaScript (and HTML & CSS) is ubiquitous. The issue of course is that every browser is "especially" different. So it makes no sense to deploy browser extensions unless things need to talk to other local apps. It makes more sense to develop hybrid native apps which are mostly html5 using something like QtWebKit and add your own per-platform goop rather than try to use something like node-webkit, phonegap (cordova) or appcelerator, because, inevitably, system-specific code will be needed, and not having direct access to APIs because of limited proxy/thunk/trampoline code doesn't make for happy developers. Java tried to do the hybrid way using JNI, which could load dll's, dylib's and so's dynamically (I wrote a custom, cross-platform (Linux, Windows), CD-ROM-based app installer using Java + JNI in 1995 by the way, it was trivial.. And then I wrote a Java source to MIPS binary, direct, non-JIT compiler in C++ in 1999.).
It was written clean-room in some client's office (no NDA, but still, engineering ethics), but I may have a copy somewhere on a backup in offline IRL storage, but it was written for JDK 1.2-1.4 IIRC so it won't run and it's chocked full of confidential / proprietary apps (which it installs). It called a few C Win32 APIs to create icons and write registry entries, on Linux I think it just wrote files and maybe ran `ldconfig`. It was super dumb, fugly but it shipped and worked consistently. There was even Swing (pre-AWT) skinnable branding background images. It was probably 450 lines of Java and 80 lines of C. Autoplay even worked decently on Windows and it came up in under 8 seconds because I optimized the ISO image for file load order to minimize seeks, and that's booting an entire 1.4 JRE from a 4x CD-ROM drive to a usable, interactive state.
> "Disabling Java in your preferred browser is for now is a better option. Use a secondary browser with Java enabled to view sites you absolutely must visit and which require it."
Do news sites say things like "Not using Safari is for now a better options" whenever somebody reports an exploitable security flaw in Safari or WebKit?
In this case, it's an easier statement to make, though, because Java is totally unnecessary for the vast majority of users. I've had it disabled for many years.
Whenever people see a headline like "Java Vulnerability Found!", it is virtually always referring to the client-side applet plugin. Yet 99% of readers don't understand that, and think that Java is insecure in general.
Whenever people see snark about Java installing the "Ask.com Toolbar", it is referring to the client-side JRE installer (i.e. applet plugin). That's virtually irrelevant to developers, because we install the full SDK which contains no crapware and never has. Yet 99% of readers don't understand that, and think that being a Java developer means dodging malware with every upgrade.
Java applets are basically the non-Microsoft business world's answer to ActiveX. A dead 1990's technology that no one has cared about in 15 years or more, which only still exists to support backwards-compatibility for some horrible crusty shops still running on XP or even NT/2000. No contemporary Java developer gives a fuck about applets, and by "contemporary" I mean "any greenfield development done since 9/11". However, we're all sick to death of having to defend our ecosystem against constant FUD, due to this horrible piece of obsolete legacy cruft.
Just kill it. Seriously.