Stolen certificate hosted on legit site by default trusted as safe by plugins.

Researchers have found a shortcoming in key security protection recently introduced in the browser plugin for Oracle's Java software framework, a flaw that makes it easier for attackers to sneak malware onto end-user computers.

By default, the widely used plugin doesn't check the status of digital certificates used to sign Java apps hosted on websites, Ars Technica has confirmed. As a result, Java presents certificates as trustworthy even when they've been reported as stolen and added to publicly available revocation databases. The failure of Java to check certificate revocation lists came to light on Tuesday when a legitimate site was found hosting a malicious app. Java presented an accompanying certificate as a trusted credential belonging to Texas-based Clearesult Consulting Inc. even though the firm had issuer GoDaddy revoke the certificate in December.

"Java thinks the stolen certificate used is 100% valid and should be trusted," Jindrich Kubec, director of threat intelligence at antivirus provider Avast, wrote in an e-mail. Referring to certificate revocation lists and an alternate method for invalidating credentials known as the online certificate status protocol, he added: "With CRL/OCSP it would make it untrusted and probably present completely different dialogues or even won't allow running the applet at all—unfortunately, the situation is a bit complicated with testing this behaviour, so I can't tell for sure which of the above would be true."

The failure to vet the status of certificates dilutes a key security protection Oracle recently added to Java. Starting in January, the default security configuration was set to "high," causing a browser to seek user permission before running unsigned apps. Since Java treats apps signed by a compromised certificate as trusted, there's the possibility that end users will receive no such prompt, a shortcoming that significantly diminishes the benefit of this important new measure. Even if users are prompted, the dialog informs them the app is trusted without taking the time to see if the underlying certificate is still valid. That omission makes it hard for users to make an informed choice. As Kubec explained, the precise behavior is hard to determine. Certificate thefts have long been a favorite tactic for sneaking malware past computer security checkpoints.

An Oracle blog post documenting the Java security settings doesn't clarify, and Oracle representatives didn't respond to an e-mail seeking comment for this post. Sadly, an e-mail sent to 13 valid addresses inside the company's PR department didn't even receive an acknowledgement that the request had been received.

Oracle should be commended for the change it introduced in January, which caused browser plugins—at least in some cases—to prompt users before running Java apps. Moves that limit functionality or require end users to click through prompts are usually extremely difficult to implement because marketers want their software to be as easy as possible to use. Requiring prompts where they previously hadn't been required was a courageous step and the right thing to do, given the steady stream of Java-based attacks found online over the past year that surreptitiously install highly malicious software on computers.

But the move is clearly not enough. The malicious Java app discovered earlier this week was hosted on a legitimate German dictionary website that was most likely compromised by the same party that planted the attack. Given this real-world threat, Ars once again advises readers who don't regularly use Java to consider uninstalling it altogether, uninstalling just the Java browser plugin, or using a dedicated browser to access the handful of sites they frequent that require Java and using a different, non-Java-enabled browser for general surfing. At the very least, those running Java should access the program's advanced settings and check the box next to "Check certificates for revocation using Certificate Revocation Lists (CRLs) and set Java's security level to "very high" under the general security tab.

This is a huge fail by Oracle. Sadly, they are far from the only one who skips checking CRLs.

Using CRLs brings up a whole bunch of other issues though, so depending on how you use them they can be just as bad.

What is the failure mode if you can't contact the CRL? If you use deny-on-failure then you've just opened a massive potential for DoS attacks - if someone can disable a CRL provider then you instantly cause certificates to be rejected everywhere. Preventing the CRL provider from being successfully used isn't too hard, DoS attack on it, make it not resolve properly via DNS etc. Accept-on-failure just means if you take it out then it's the same as not having one.

How do you authenticate the CRL? It is signed by any of the normal CAs, or do you have your own trusted certificates for it? How do you handle the CRL provider being compromised, which is just as bad as a CA being compromised.

Do you use general CRL infrastructure, or do you have your own (in this case Java app) CRLs? If it's the former, should signing malware get you on it, if the certificate wasn't fraudulently issued?

If you want to use CRLs when checking certificates, you need to do a lot of thinking about what you actually want to happen, and using them correctly is HARD.

That's a really good point. It isn't as simple as "just make sure to check the CRL", but I don't think that the difficulty of the problem excuses Oracle from not checking them at all. It raises a bunch of questions, but these are questions that can be answered (and have been answered numerous times before in other software development projects).

Airbags are essentially small explosives that create enough gas to quickly fill a canvas bag, to absorb the energy of a driver or passenger hitting the dash. I'm certain that they are extremely complicated devices, and there are all kinds of failure modes possible. I remember (years ago now) people being seriously injured when airbags deployed inappropriately (for instance, during extremely low-speed collisions, such as in the supermarket parking lot). This doesn't mean that airbags raise too many difficult questions to be used effectively. It just means that engineering effort is needed in order to build the proper solution to the problem.

Users can forbid the use of Java in the Internet Zone by setting the Windows registry key 1C00 to 0 under HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones3 and allowing Java only on whitelisted websites in the Trusted Zone, Kandek said Monday in a blog post.

I'm curious. Every single one of these security exploits that have cropped up recently have existed pretty much since the feature was implemented, long before Oracle acquired Java, and most have long been visible in source form since OpenJDK was released years ago. So why are they all coming to light now? I would think there would've been more focus on finding Java exploits back when Java Applets were more popular, not today. How did Sun manage to luck out and not have it's reputation completely tarnished for all the horrible code it wrote?

We all want browser plug-ins to die, right? Well we need to do precisely nothing for that to happen, very very soon. The two most common plug-in developer firms are going out of their way to sabotage their own products. They are practically competing for the title of the most shoddy software available for a PC.

@pavon: not necessarily. the article about the patch released monday (or over the weekend) said that it was fixing an exploit specifically targeting 6u41. i interpret that to mean that these "patches" they're pushing out may be plugging existing holes but at the same time opening new ones.

i would LOVE for our firm to uninstall java, but business would slam to a halt without it. it's sad.

not necessarily. the article about the patch released monday (or over the weekend) said that it was fixing an exploit specifically targeting 6u41. i interpret that to mean that these "patches" they're pushing out may be plugging existing holes but at the same time opening new ones.

i would LOVE for our firm to uninstall java, but business would slam to a halt without it. it's sad.

Remember, it's the plugin that needs to die already. However, there are some companies who use legacy Java applets for mission-critical apps, like the old timesheet software at one of my former employers. We did manage to switch to a different timesheet software that was a webapp, but it had some features that only worked reliably in IE (much to my discontent, but as I didn't want to get fired, I dealt with it).

You are referring to the Java plugin, but to assume that's all Java does is very wrong. Yes, the Java plugin needs to die, but NO ONE wants to (or is willing to) give HTML5 and JS direct access to your database (very bad, very wrong, and very dangerous). Java's true niche is the servlets and JSPs that ensure reliable and secure ways to access data from the database and power your HTML5 web applications.

Sure, one can argue .NET and/or PHP (and the multitude of other languages you can use), but there are fewer developers for those languages than for Java.

I'm talking about the plugin - not the host language environment. I added the word "plugin" to my post to make that clear. I thought it was clear already, but apparently not, so now it should be.

It helps to be clear. I'm just tired of everybody else bashing the whole framework instead of doing what should be done: grabbing our LARTs and finding the guy who coded the plugin this way. I don't think it was Gosling who made the Java plugin, so I feel good about this.

This is a huge fail by Oracle. Sadly, they are far from the only one who skips checking CRLs.

Using CRLs brings up a whole bunch of other issues though, so depending on how you use them they can be just as bad.

What is the failure mode if you can't contact the CRL? If you use deny-on-failure then you've just opened a massive potential for DoS attacks - if someone can disable a CRL provider then you instantly cause certificates to be rejected everywhere. Preventing the CRL provider from being successfully used isn't too hard, DoS attack on it, make it not resolve properly via DNS etc. Accept-on-failure just means if you take it out then it's the same as not having one.

How do you authenticate the CRL? It is signed by any of the normal CAs, or do you have your own trusted certificates for it? How do you handle the CRL provider being compromised, which is just as bad as a CA being compromised.

Do you use general CRL infrastructure, or do you have your own (in this case Java app) CRLs? If it's the former, should signing malware get you on it, if the certificate wasn't fraudulently issued?

If you want to use CRLs when checking certificates, you need to do a lot of thinking about what you actually want to happen, and using them correctly is HARD.

Look, I loathe Java as much as anyone. And this rash of security holes pisses me off to no end. I hate it and I wish I could be rid of it.

But please stop spouting the whole "the best fix is to uninstall it" nonsense. Yes, of course that will stop the security holes. But if you're an IT professional, this isn't an even remotely realistic option. It's also a painfully obvious suggestion that doesn't add anything useful to the conversation. You're essentially just dismissing the problem most users face: "How do I run Java plugins and still keep my computer safe?"

In the real world, you can't go around saying "Sorry everybody, half of the institutional websites you rely on are no longer available. But it's Oracle's fault! Java is baaaad!"

This is a huge fail by Oracle. Sadly, they are far from the only one who skips checking CRLs.

Using CRLs brings up a whole bunch of other issues though, so depending on how you use them they can be just as bad.

What is the failure mode if you can't contact the CRL? If you use deny-on-failure then you've just opened a massive potential for DoS attacks - if someone can disable a CRL provider then you instantly cause certificates to be rejected everywhere. Preventing the CRL provider from being successfully used isn't too hard, DoS attack on it, make it not resolve properly via DNS etc. Accept-on-failure just means if you take it out then it's the same as not having one.

How do you authenticate the CRL? It is signed by any of the normal CAs, or do you have your own trusted certificates for it? How do you handle the CRL provider being compromised, which is just as bad as a CA being compromised.

Do you use general CRL infrastructure, or do you have your own (in this case Java app) CRLs? If it's the former, should signing malware get you on it, if the certificate wasn't fraudulently issued?

If you want to use CRLs when checking certificates, you need to do a lot of thinking about what you actually want to happen, and using them correctly is HARD.

That's a really good point. It isn't as simple as "just make sure to check the CRL", but I don't think that the difficulty of the problem excuses Oracle from not checking them at all. It raises a bunch of questions, but these are questions that can be answered (and have been answered numerous times before in other software development projects).

Airbags are essentially small explosives that create enough gas to quickly fill a canvas bag, to absorb the energy of a driver or passenger hitting the dash. I'm certain that they are extremely complicated devices, and there are all kinds of failure modes possible. I remember (years ago now) people being seriously injured when airbags deployed inappropriately (for instance, during extremely low-speed collisions, such as in the supermarket parking lot). This doesn't mean that airbags raise too many difficult questions to be used effectively. It just means that engineering effort is needed in order to build the proper solution to the problem.

As to why it won't die: e.g. in my country, the tax return and numerous other things can only be submitted online through a java applet. Yes, you read it right, and yes, it is fucked up. Better yet, calling the apps rubbish would be an insult to actual rubbish.

"C is a dangerous language. There are many, many security exploits involving C. Thereby, C should be killed."

That's basically what a lot of the anti-Java as a language folks are posting on various parts of the Intartubes. The real problem is not with Java, but with the Java plugin. Just like running arbitrary C code in your browser is a bad idea, we're now realizing that running arbitrary Java code in the browser is almost as bad. However, if you're not running it as a plugin, Java's a fine language for many things. Keep it on the desktop and the server, but chuck it from the browser.

Users can forbid the use of Java in the Internet Zone by setting the Windows registry key 1C00 to 0 under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 and allowing Java only on whitelisted websites in the Trusted Zone, Kandek said Monday in a blog post.

Look, I loathe Java as much as anyone. And this rash of security holes pisses me off to no end. I hate it and I wish I could be rid of it.

But please stop spouting the whole "the best fix is to uninstall it" nonsense. Yes, of course that will stop the security holes. But if you're an IT professional, this isn't an even remotely realistic option. It's also a painfully obvious suggestion that doesn't add anything useful to the conversation. You're essentially just dismissing the problem most users face: "How do I run Java plugins and still keep my computer safe?"

In the real world, you can't go around saying "Sorry everybody, half of the institutional websites you rely on are no longer available. But it's Oracle's fault! Java is baaaad!"

Or maybe just maybe if the java penetration was dropped to such a level corporations would rethink of using this crappy framework and plugin. It's clear the java programmers have no idea what they are doing, how retarded to you need to be to not check the certificate revocation - that's kinda the basic step in certificate authentication. If they are that lax about security in the plugin how bad is the framework itself? I'd say it's pretty bad and the tip of the iceberg has been found so far.

Uninstall Java and eventually corporations will have to deal with it by rewriting their applications. This is equivalent to corps still running IE6 and plan to do so till 2100. Force change don't accept mediocrity. When I find websites that use Java - I don't go back. When I find applications with a Java requirement I don't install them.

Or maybe just maybe if the java penetration was dropped to such a level corporations would rethink of using this crappy framework and plugin. It's clear the java programmers have no idea what they are doing, how retarded to you need to be to not check the certificate revocation - that's kinda the basic step in certificate authentication. If they are that lax about security in the plugin how bad is the framework itself? I'd say it's pretty bad and the tip of the iceberg has been found so far.

The framework is no worse than C/C++. Are you advocating we also ditch C/C++ as well? Or are you only limiting this discussion to the plugin? Your post was a bit unclear to me.

So long as you stick to Java applications, not applets, running on the desktop or server that came from respectable developers, you're fine. Running any arbitrary code, no matter the implementation language, can be a dicey matter. The problem with Java in the browser is the same as theoretical C/C++ in the browser: it's arbitrary code using a language and framework without appropriate limitations for browser usage. HTML5/JavaScript get around this by baking-in a lot more limitations to the browser and by being more limited languages in general. Java was basically designed to be a more portable C++ and the problems with this design are starting to show.

Or maybe just maybe if the java penetration was dropped to such a level corporations would rethink of using this crappy framework and plugin.

Crappy plugin: Yes.Crappy framework: No.

Try developing an application for Java sometime, whether it be a Web application or a desktop application. You'll be amazed at what you can do.

pg2 wrote:

It's clear the java programmers have no idea what they are doing, how retarded to you need to be to not check the certificate revocation - that's kinda the basic step in certificate authentication.

Like the guy in one of the earlier posts said, it isn't as simple as you're trying to make it out to be. Yes, Oracle could have put in some checking on certificates.

pg2 wrote:

If they are that lax about security in the plugin how bad is the framework itself? I'd say it's pretty bad and the tip of the iceberg has been found so far.

Give me one example within the lifetime of Java (about 15-16 years) of somebody hacking the JVM directly and executing code that way.

pg2 wrote:

Uninstall Java and eventually corporations will have to deal with it by rewriting their applications. This is equivalent to corps still running IE6 and plan to do so till 2100. Force change don't accept mediocrity. When I find websites that use Java - I don't go back. When I find applications with a Java requirement I don't install them.

On the IE6 thing, corporations will move away since the EOL for Windows XP is quickly approaching, even for extended support. On the rewriting apps portion, do you know how much effort of rewriting some applications will take? It isn't an overnight "NEW VERSION!". It's a prolonged process that requires resources (money) that could be used more efficiently somewhere else. The pyramids weren't built in one day you know.

"C is a dangerous language. There are many, many security exploits involving C. Thereby, C should be killed."

That's basically what a lot of the anti-Java as a language folks are posting on various parts of the Intartubes. The real problem is not with Java, but with the Java plugin. Just like running arbitrary C code in your browser is a bad idea, we're now realizing that running arbitrary Java code in the browser is almost as bad. However, if you're not running it as a plugin, Java's a fine language for many things. Keep it on the desktop and the server, but chuck it from the browser.

I think that's what most people are championing. However, a lot of people are finding they don't need it for desktop either. It has many enterprise uses, but not so many home uses. (I haven't hit anything in the home desktop space that used it in the last five years (and I'm a developer!), and the only one I can think of that a home user would have is Minecraft.) This is one reason why people might recommend it be turned off for home use: most people don't need it.

We all did the same thing with Flash a few years ago too. "Ack! Why does everything use Flash? Get it away!" The truth is, anytime anything can run arbitrarily from an unknown source, it's bad. Coincidentally, I've been going for two months without Flash installed either. So far, I haven't needed it.

Or maybe just maybe if the java penetration was dropped to such a level corporations would rethink of using this crappy framework and plugin. It's clear the java programmers have no idea what they are doing, how retarded to you need to be to not check the certificate revocation - that's kinda the basic step in certificate authentication. If they are that lax about security in the plugin how bad is the framework itself? I'd say it's pretty bad and the tip of the iceberg has been found so far.

The framework is no worse than C/C++. Are you advocating we also ditch C/C++ as well? Or are you only limiting this discussion to the plugin? Your post was a bit unclear to me.

So long as you stick to Java applications, not applets, running on the desktop or server that came from respectable developers, you're fine. Running any arbitrary code, no matter the implementation language, can be a dicey matter. The problem with Java in the browser is the same as theoretical C/C++ in the browser: it's arbitrary code using a language and framework without appropriate limitations for browser usage. HTML5/JavaScript get around this by baking-in a lot more limitations to the browser and by being more limited languages in general. Java was basically designed to be a more portable C++ and the problems with this design are starting to show.

With the plugin written so poorly - this is tantamount to having a very faulty vault door at a bank. If the door is so faulty how do you know the walls inside it are also not a crumbling pile of dirt? I don't trust any part of Java so I'm not limiting it to anything - uninstall the entire thing - JRE, plugin and if you see applications/applets or anything that require it tell it NO it is not coming onto my computer.

The JRE itself allowed remote execution, so the idea of just blocking the plugin simply is not good enough if you think that will protect you. The entire java stack is invested with poor programming and now a manager (oracle) who is not sleeping at the wheel but is awake and psychopathically conscious and trying to cause an accident - they simply do not care.

"C is a dangerous language. There are many, many security exploits involving C. Thereby, C should be killed."

That's basically what a lot of the anti-Java as a language folks are posting on various parts of the Intartubes. The real problem is not with Java, but with the Java plugin. Just like running arbitrary C code in your browser is a bad idea, we're now realizing that running arbitrary Java code in the browser is almost as bad. However, if you're not running it as a plugin, Java's a fine language for many things. Keep it on the desktop and the server, but chuck it from the browser.

I think that's what most people are championing. However, a lot of people are finding they don't need it for desktop either. It has many enterprise uses, but not so many home uses. (I haven't hit anything in the home desktop space that used it in the last five years (and I'm a developer!), and the only one I can think of that a home user would have is Minecraft.) This is one reason why people might recommend it be turned off for home use: most people don't need it.

We all did the same thing with Flash a few years ago too. "Ack! Why does everything use Flash? Get it away!" The truth is, anytime anything can run arbitrarily from an unknown source, it's bad. Coincidentally, I've been going for two months without Flash installed either. So far, I haven't needed it.

Well, Flash serves no real useful purpose either... except for some clueless websites... but that's besides the point (for now).

I can name two Java based apps that a home user may use, however. One is LibreOffice/OpenOffice.org if you use their built-in HSQLDB database. Why they used HSQLDB instead of something like SQLite, I have no idea, but they did. The other is the Moneydance personal finance application. Both of these I use regularly. Of course, I'm a developer myself, so I have Java around for lots of other stuff... I also have some more obscure apps that I use for special purposes, but I can't envision them being the types of apps the average home user would be using.

Or maybe just maybe if the java penetration was dropped to such a level corporations would rethink of using this crappy framework and plugin.

Crappy plugin: Yes.Crappy framework: No.

Try developing an application for Java sometime, whether it be a Web application or a desktop application. You'll be amazed at what you can do.

pg2 wrote:

It's clear the java programmers have no idea what they are doing, how retarded to you need to be to not check the certificate revocation - that's kinda the basic step in certificate authentication.

Like the guy in one of the earlier posts said, it isn't as simple as you're trying to make it out to be. Yes, Oracle could have put in some checking on certificates.

pg2 wrote:

If they are that lax about security in the plugin how bad is the framework itself? I'd say it's pretty bad and the tip of the iceberg has been found so far.

Give me one example within the lifetime of Java (about 15-16 years) of somebody hacking the JVM directly and executing code that way.

pg2 wrote:

Uninstall Java and eventually corporations will have to deal with it by rewriting their applications. This is equivalent to corps still running IE6 and plan to do so till 2100. Force change don't accept mediocrity. When I find websites that use Java - I don't go back. When I find applications with a Java requirement I don't install them.

On the IE6 thing, corporations will move away since the EOL for Windows XP is quickly approaching, even for extended support. On the rewriting apps portion, do you know how much effort of rewriting some applications will take? It isn't an overnight "NEW VERSION!". It's a prolonged process that requires resources (money) that could be used more efficiently somewhere else. The pyramids weren't built in one day you know.

That was less than 2 months ago, REMOTE EXECUTION VUNERABILITY - an attacked can take over your entire machine just from having the JVM installed - no plugin needed.

Rewritting applications isn't that complex - I write software for a living - yes it takes time. This is about saving money and not wanting to rewrite things that already work - regardless of security. You are mistaken if you think corps will move away from XP; they only will once they start getting completely hacked to sh8.