Faced with an onslaught of malware attacks that leverage vulnerabilities and design weaknesses in Java, Oracle Corp. recently tweaked things so that Java now warns users about the security risks of running Java content. But new research suggests that the integrity and accuracy of these warning messages can be subverted easily in any number of ways, and that Oracle’s new security scheme actually punishes Java application developers who adhere to it.
Java’s security dialog box.
Running a Java applet now pops up a security dialog box that presents users with information about the name, publisher and source of the application. Oracle says this pop-up is designed to warn users of potential security risks, such as using old versions of Java or running applet code that is not signed from a trusted Certificate Authority.
Security experts differ over whether regular users pay any mind whatsoever to these warnings. But to make matters worse, new research suggests most of the information contained in the pop-ups can be forged by malware writers.
In a series of scathing blog posts, longtime Java developer Jerry Jongerius details the various ways that attackers can subvert the usefulness of these dialog boxes. To illustrate his point, Jongerius uses an applet obtained from Oracle’s own Web site — javadetection.jar — and shows that the information in two out of three of its file descriptors (the “Name” and “Location” fields) can be changed, even if the applet is already cryptographically signed.
“The bottom line in all of this is not the security risk of the errors but that Oracle made such incredibly basic ‘101’ type errors — in allowing ‘unsigned information’ into their security dialogs,” Jongerius wrote in an email exchange. “The magnitude of that ‘fail’ is huge.”
Jongerius presents the following scenario in which an attacker might use the dialog boxes to trick users into running unsafe applets:
“Imagine a hacker taking a real signed Java application for remote desktop control / assistance, and placing it on a gaming site, renaming it ‘Chess’. An unsuspecting end user would get a security popup from Java asking if they want to run ‘Chess’, and because they do, answer yes — but behind the scenes, the end user’s computer is now under the remote control of a hacker (and maybe to throw off suspicion, implemented a basic ‘Chess’ in HTML5 so it looks like that applet worked) — all because Oracle allowed the ‘Name’ in security dialogs to be forged to something innocent and incorrect.”
Oracle has not responded to requests for comment. But Jongerius is hardly the only software expert crying foul about the company’s security prompts. Will Dormann, writing for the Carnegie Mellon University’s Software Engineering Institute, actually warns Java developers against adopting a key tenet of Oracle’s new security guidelines.
Oracle recommends that all Java applets be cryptographically signed regardless of the privileges required by the program. Unsigned Java applets will run within a web page with a scary red warning that, “Running this application may be a security risk.” One of Java’s most-touted features is a “sandbox” security mechanism that is supposed to prevent certain functions when the applet is sent as part of a Web page. But according to both Jongerius and Dormann, Oracle made the default behavior for signed code to be full access to the computer (essentially, negating the usefulness of the sandbox).
“What about Oracle’s vision of a Java future where every Java applet is signed?,” asks Dormann, a longtime security research with the Department of Homeland Security’s US Computer Emergency Readiness Team (US-CERT). “What this vision means is that every Java applet, which would be signed, would also now be in a state where it could be repurposed because it is now no longer restricted by the sandbox. A poorly designed sandboxed Java applet can’t do much of anything. However, a poorly designed signed Java applet can do pretty much anything that native code can.”
Both Dormann and Jongerius offer a number of ideas that Oracle could use to remedy the situation. Only time will tell if the company will take notice of the recommendations. In the meantime, I’ll continue to urge regular Internet users to get rid of Java completely, or at least to disconnect the Java plugin from any Web browsers (obligatory disclaimer: this advice does not scale for business users, whose computers may rely on Java for specific applications).
Hi,
Microsoft is also showing such meta data in its UAC dialog.
Have you or other verified, that changing this meta data will at least break the digital signature on Windows, so that the dialog will be in red color?
try to run %windir%\system32\cmd.exe as admin, UAC box is green.
copy %windir%\system32\cmd.exe to (for example) %userprofile%\blablabla.exe and try to run as admin.
UAC box is in orange colour, and says “unknown publisher”.
This isn’t a good example: cmd.exe isn’t actual signed.
That you will get a green UAC box when you start cmd.exe in %windir%\system32\ is an exception. Maybe I’ll find the the TechNet article somewhere…
In the meantime:
Try to find a 3rd party executable, which requires administrator privileges in its embedded manifest and which is actual signed.
The answer to that is obvious. Microsoft aren’t amateurs.
“3rd party executable actually signed which needs admin”
how about a 1st party executable, properly signed which needs admin? ie, NT 6.x setup.exe?
which, btw, i tried. it shows the valid signed UAC dialog no matter what filename it is, but it always says “Program name: Microsoft Windows” (not sure where exactly that is pulled from, maybe the signature? not the VS_VERSION_INFO resources at least) no matter what filename it is.
Look at all those unsigned parameters, like the class whose main() gets invoked.
http://docs.oracle.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html
Developers will often have a lot of utility classes and third party classes in signed jar files. Search the web for jar files signed by trusted companies and find a main() method that was never meant to be invoked from javaws with arbitrary parameters by an attacker…and host it on your web server with an appropriately malicious jnlp file.
As a Java developer for 5+ years, I always considered Applets to be avoided. I always deactivated any browser Java plug-in. Can’t clearly explain why, but I always felt like Java is made for desktop enterprise applications or websites, but not applets. Hmzz.
I agree, I am a long time java programmer and I don’t even like applets. I think even the idea of running applets from a website is stupid. The web should go html+js+css and not Java. Java should stick to desktop and enterprise apps.
The main problem is that the wrong thing is being signed. It’s ok to have a jnlp file with a plaintext body that includes parameters and references to referenced resources (like jar files) … with their size and strong hashes, and a signature for this file.
Where it falls down is in signing the code, but allowing it to be parameterized by the entity serving up the file (ie: not the user, but an attacker). The author should give a signature for the one purpose for which the app is designed; therefore, signing the jar files rather than the top-level jnlp actually creates security holes.
Beats me why no one has questioned why this company & its product is still around.
In a normal competitive free market it would have become history being superceded by something better, so WTF.
All I can think is it must be on the Big Government Plantation.
Java is actually really excellent as far as languages go, and has security features that aren’t even thinkable in most languages. Signed Python would have more problems for example. Particularly in servers, the language makes it really easy to defend against and sandbox out bad input coming from the outside. Hadoop is one shiny example where it even has world-record performance benchmarks to its name.
Applets are and have always been a bad idea, largely because you are dealing with native plugins to host it in a messy environment like web browsers; and I don’t understand why applets still exist. They should have been disabled by default the moment JavaWebStart became available, and a hard look taken at hardening web start. WebStart’s principal flaw is just that it signs code rather than a manifest of everything that says how to launch an app, and every environment that signs code bundles instead of the manifest that uses it suffers from the same flaw.
I worry that since Oracle acquired it, a lot of the incentives to fix problems just went away.
Hello, Jerry Jongerius here. I thought you all would enjoy a reply that I received from Oracle (indirectly) on this issue as a result of your article.
Oracle’s answer: “give a flying fuck”. Someone from Oracle (137.254.4.13, inet-aumc10-o.oracle.com) left me that message in my webpage (http://www.duckware.com/tech/javafailure.html) that allows anyone to control the name in the security dialog.
To authenticate this comment, I have posted http://www.duckware.com/tech/137.254.4.13.txt, the web logs of this Oracle employee.
With that attitude, it is no wonder Java has so many security issues…
This is certainly scary for the layuser, who as all of us have, been prompted by similar Java warnings to either proceed or not. After seeing the warnings dozens of times and hearing the soft warning sound, you do become immune to it, and stop reading the actual warning altogether. Human complacency in this case leads to potentially easy targets.
The ability to accept these warning messages should be taken out of the hands of the layuser. The only way to really do this is to physically separate the browser from the user’s computer- an air gap browser such as the one by Spikes. That way, no matter how much a user fusses with these warning messages, there will be minimal consequences in the form of malware attacks.
Ive been in the Information Assurance, cyber security field for quite some time. You see patterns of abuse on software that is prominent and usually lasts for a few years until the company decides to fix the embotchment.
The crooks know that some organizations are doomed. They have proprietary software that has java built in. Until they move on to something else, they are going to use java forever.
Its not only Java’s fault. There are other security controls which can be put in place to circumvent all of this, but it takes plenty of people, skills and vigilence to get past the miscreants.
Java in many organizations is the tlak of the town. Many are talking about the punting of java and moving back to basics like HTML5. HTML5 is snappy, it looks clean and its new.
That amounts to a hill of beans though, because as people move from one style of software to another, the crooks see this. the crooks can turn around a new vulnerability pack quite fast. To me that means they are continually monitoring what is being used out in the real world, and are at the ready to continually pester / infest as many clients as they can.
Java is another agent that has security by obscurity. The lax security obviously is somewhat acceptable there and obviously acceptable in the public sector. The “attention to detail” for most end users is simply not there, they just “need” to click and go with the minimal amount of interruptions in the thought process – if one wants to call it that.
People consider big businesses safe, and since it is big and somewhat legit, why not add this stuff on my machine or mobile device? What are the odds that some bug is going to infect MY device? hardly….. Common ! I have antivirus !
Java is littered with controls that I have NO idea why they are there, especially if they aren’t controlled by the user who owns the machine. Those are suspect in my book. The ability to disable these settings are quite buried, and the end users usually have NO clue how to delete their browser history, let alone try to clear it in Java.
Java needs a complete revamping. The Elder-Person in charge, sitting on its buttocks, is probably afraid of the change to something more secure. They need to have faith in the developers and allow them to do what is (supposedly) right, and redo java with more security in mind.
It’s a Tiny Tugboat trying to pull up a sunken oceanliner. Unless everyone on board is willing to go all in, and they are in concert, any software – not just java – is doomed to be a part of the crooks malware package.
One potential solution I’ve advocated in the past is to use a non-Oracle Java platform. There are quite a few commercial versions out there in both embedded and server markets. Harmony showed the most potential in open source till it got killed off. Code is still there to use, though. Diverse codebases and implementations is helpful in itself. However, it can be taken further like Aonix’s more robust JVM’s or the one’s that run on a Java chip. The embedded one’s can also often be implemented on MILS-type RTOS’s like Integrity or PikeOS. Reduces TCB quite a bit.
There’s plenty of solutions out there which would probably be safer than Oracle’s platform. Many can be used on the server, a few deployed in desktop solutions, and others in appliance or add-on card solutions. Just gotta roll it out. Seems like the best idea for an interim solution until a full Java revamp (that will never happen under Oracle).
Your thoughts?
IA Eng, an excellent post indeed!
Java is a failed project from the nineties. It was used to test the coding for embedded devices. Scott McNealy brought it as a virtual machine à la Basic in the early seventies. McNealy used the technique to spread it free through all kind of educational institutes and other programming communities, so it could gain momentum.
The same chain of events as with Basic followed which led to C# for instance…
Java is nothing more then C++ with a different library!
It was never intended to be secure or to have the role in IT as it has nowadays.
Just because you got to learn it on school, because it’s free, made it popular.
IMHO! Java still exists because the developers of today never got to the skill level to see that it’s a junk platform. It’s just there to learn you the basic skills of programming!
Stop using Java for serious business! Use C++ instead for server based apps or HTML5 for client based apps… please…
This whole post is about safely running known-hostile code in clients, which the Java platform actually got away with for a decade. So now, it’s being demonstrated that running known-hostile code is dangerous, because the Java sandbox isn’t tight enough.
“Use C++ instead for server based apps or HTML5 for client based apps…” — I have been working on IPS/IDS applications for the last decade, and this is possibly the worst advice that anyone could possibly follow. Just look at what the signature sets detect and the CVEs they address. The entire IDS business exists because of pointer arithmetic and exploiting memory layout (C) and code injection (scripting languages).
You use C because it’s fast (in a real-time sense), can be made to use minimal memory, easy to interoperate with other C code, and possible to reason about exactly what goes on in *small* programs. As good as those reasons are, they are the only reasons.
The presence of pointer arithmetic actually blinds C compilers to a lot of obvious vectorization and thread-safety related optimizations as well; so C will not always be the fastest language when you have dozens of CPU cores and hundreds of SIMD lanes at your disposal (something like Rust in the future? Go?).
There is certainly no security reason to choose C over Java. Whenever you figure out how to make Java do what a C program would have been able do, we call that a “security hole” in Java.
A virtual machine in which pointer arithmetic does not exist does provide a real measure of security (CLR, JVM, etc) from bad input. Our best C programmers do write Excellent Java code; and it’s often faster than the C code because you have the same amount of time (ie: money) to get it done either way. Looking at the bug fixes going into Git, C code is always being edited to defend against buffer overflows and memory leaks; while the Java code is usually being re-factored to use faster algorithms or less memory.
In C, you can actually prove a function correct, only to have it still fail in the wild because something else scribbled into its memory and violated all of the invariants. It’s often caused by a library written by somebody else. It’s sometimes caused by correct code incorrectly linked.
… Yes, Java applets should definitely be permanently disabled; and JavaWebStart protocol needs to be fixed in a non-backwards-incompatible way if it is to be used at all. But this is completely unrelated to the merits of the language. C has benefits, but helping out with security proofs is definitely not one of them.
I’m surprised anyone still uses Java anymore.
People Why are you all that surprised ??? Java is just a drop in the ocean .
disclosure, along with Edward Snowden leak reports from the Guardian and the Washington Post suggesting companies are basically turning on spigots that allow information to flow to the government nearly freely, has firms like Google scrambling to protect client privacy.
The reasoning behind bolstering encryption schemes is that governments and others who want to pry open the data of ordinary citizens will be forced to limit the scope of their hacking, technology firms argue.
‘It’s an arms race,’
Do not be surprised that all use the vulnerabilities in Java. Java was always not very safe product, but it may be any other proprietary product instead of Java. Multiple vulnerabilities have been regularly detected in Internet Explorer and Silverlight, and Adobe Flash.
But for some reason, no one needs to disable Flash Plugin or anything else.
I believe that Oracle programmers do not need to implement a signature to applets but to review the architecture of the JRE, and perhaps pay more attention to the safe operation of downloading and execution of files.
That’s all, if exploits are downloading files and execute them, no matter where vulnerability is, it is important that this vulnerability became irrelevant.