First Java Zero-Day Attack in Two Years Targets NATO and US Defense Organizations
blog.trendmicro.com
blog.trendmicro.com
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.
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.
Unfortunately not, there are MANY institutions that still rely on Java Applets.
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.
Is that "end-user" enough for you? All busness owners in the country and all other general population doing eGovernment?
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.
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?
Except ActiveX goes back to Windows 3.1 and OLE 2.0.
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.
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 don't do that anymore. http://www.pcworld.com/article/2940688/java-installer-ditche...
'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.
A car company shouldn't sell a car with defective brakes, even if the defect was great for replacement airbag sales.
>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 don't think Java is enabled by default in any install, is it? So what's the risk?
The first time I opened it and it brought up the little Java prompt, I was like, "Really?"
Fortunately, I only need to use it when I request PTO. I feel sorry for the hourly employees that use it several times a day.
Oracle's flagship ERP product is Applet-based, so I doubt that's going to happen anytime soon.
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)
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?
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.
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.
How would you address this situation?
The Web only goes so far.
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?
> How would you address this situation?
Well, first I would sign up for a github account. You know steps two and three.
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.
"[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."
https://www.securityweek.com/java-zero-day-used-attacks-nato...
Fixed that for them.
Even though it is now replaced, the install-base is still huge because people don't delete the plugins :(
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"
That is a scary thought. I guess this is what happens when you cling to using XP and IE8 after Microsoft has ended support.
Why is there never a clear distinction?
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.
Any Java application can run a SecurityManager:
http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityM...
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.
* 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?
MSFT provided a patch long time ago for this. Wouldn't it imply that applying MSFT's patch is enough?
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0...
...and how is this not a Windows vulnerability, and instead Java?
So it is a Java issue only in the sense that Oracle needs to update it. Obviously the original "bad code" was from Microsoft.
[0] https://technet.microsoft.com/en-us/library/security/ms12-02... [1] https://community.emc.com/community/connect/rsaxchange/netwi...
The closest thing to that is this, Securia PSI:
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.).
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.