Java’s latest security problems: New flaw identified, old one attacked

Flaw in latest Java version allows bypass of Java security sandbox.

A flaw identified in the latest version of Java allows for a complete bypass of the Java security sandbox, a security firm reported today. Meanwhile, a security hole recently fixed by Oracle is being targeted by attackers, underscoring the importance of installing patches quickly.

The security firm Security Explorations said today that it sent a "Vulnerability Notice along with a Proof of Concept code" to Oracle, and that Oracle has confirmed receiving the notice. "The company informs that it will investigate based on the data provided and get back to us soon," Security Explorations said.

Security Explorations CEO Adam Gowdiak told Softpedia that it tested the flaw in the original release of Java 7, as well as in Java 7 Updates 11 and 15. Java 7 Update 15 is the latest version released last week. "When combined, the flaws can be leveraged to achieve a complete bypass of the Java security sandbox," Softpedia wrote.

Few details of the flaw were shared, presumably to prevent it from being exploited by hackers. Gowdiak told Softpedia that the flaw allows abuse of the Java Reflection API "in a particularly interesting way… Without going into further details, everything indicates that the ball is in Oracle's court. Again.”

Java updates have been coming frequently lately to patch all the various security holes that have been identified by security firms and/or targeted in attacks. An attack targeting Java 7 Update 11 is now "in the wild," according to an update today from security firm Rapid7. The hole allows bypass of the security sandbox and was fixed by Oracle in Update 13 on Feb. 1. However, exploit kits used by attackers now reportedly target this flaw. The good news is that user interaction is required to run the exploit—no infections will occur unless the user clicks "Run" when asked "Do you want to run the application?"

We've advised before that users who don't need Java should consider uninstalling it, or at least the Java plug-ins used to run Java content in Web browsers. Even savvy computer users aren't necessarily safe. An iPhone developer forum was found last week to be hosting malware targeting Java-enabled computers—resulting in attacks targeting employees of Facebook, Twitter, and Apple.

Has Java always been this insecure? or is it really going downhill because it was acquired by Oracle?

It never has really been secure, at least when tied to the browser. It's actually not too bad when used outside of the browser by apps.

I am wondering if some of this is a change by the head of Java security. I don't know if it's a new position, but the person in the job now has only been with Oracle about 6 months. So he might be trying to make things right as well.

Has Java always been this insecure? or is it really going downhill because it was acquired by Oracle?

Hard to say -- Java's probably always been insecure, but since all these recent attacks are on the "new" version of Java 7 (which was written by Oracle), and not Java 6 (which was written when Java was owned by Sun), I would say that it's because of Oracle's sloppiness.

Full disclosure: I've been using Oracle's DB for 12+ years and hate Larry with a passion -- so my views may be distorted.

Has Java always been this insecure? or is it really going downhill because it was acquired by Oracle?

It never has really been secure, at least when tied to the browser. It's actually not too bad when used outside of the browser by apps.

I am wondering if some of this is a change by the head of Java security. I don't know if it's a new position, but the person in the job now has only been with Oracle about 6 months. So he might be trying to make things right as well.

That's the problem with the web plugin having all of the power of the environment used for local programs. Security problems for a browser plugin can be important features for a an actual program.

Are there any browsers that run Java in a low privilege process? If they break out of the "security sandbox", what access rights do they have? The same as the user? Does the JRE always have / require admin rights?

Almost all of these recent Java security problems are with version 7, and most of them use reflection to bypass the sandbox. I've looked, but there weren't many big changes in the Java reflection API, so it looks like the root of these problems are in the sandbox implementation in the JVM and not from changes to the API. Any reason why they can't revert back to how things were done in the relatively secure Java 6 series?

It is beginning to look like Oracle doesn't know how to properly handle security, Java, or both (my money is on both). I've heard the rumor that large numbers of Java developers at Sun quit rather than work for Oracle. Any truth to this?

I just wish it was easier to remove plugins (not extensions; those are easy enough) from browsers AND to block those extensions from re-installing.

There's plenty of reason to have Java/JVM on a computer (at least for some). There's not much reason to have the java plugin on your web browser.

I've run into the same issue when trying to get rid of craptastic plugins from other software as well (I'm looking at you AVG). You can do it if you know how, but it's a pain and it doesn't prevent reinstall.

I'm sure Oracle is so glad they chose to expand the Reflection API in Java 7. Apparently the ability of code to inspect and modify itself (and the underlying environment) might be abusable if implemented imperfectly. Who'd a thunk it?

I just wish it was easier to remove plugins (not extensions; those are easy enough) from browsers AND to block those extensions from re-installing.

There's plenty of reason to have Java/JVM on a computer (at least for some). There's not much reason to have the java plugin on your web browser.

I've run into the same issue when trying to get rid of craptastic plugins from other software as well (I'm looking at you AVG). You can do it if you know how, but it's a pain and it doesn't prevent reinstall.

Unfortunately I work in one of many, many businesses that use systems built using Java web plugins and Adobe Reader/Acrobat. It's a ticking time-bomb.

The core of the problem is that certain parts of Java 7 API need access to protected methods of other classes. This is completely normal, and package level access is a good solution (as opposed to public, protected or private declarations). However, if your classes are in different packages, then this no longer works, and the Reflection API is "abused" to get the required access. The Reflection API goes into great length to verify that the user really should have privileged access to private and protected classes and methods (by the way this is why reflection is slow), but this is manual code sprinkled everywhere that is very difficult to get it right. Moreover, the Java 7 has introduced the invoke dynamic primitive in the VM and the reflection API is extended accordingly. This is not completely secured yet, or its interaction of the other parts of the security framework is not completely understood. This is why we are seeing so many exploits. If the reflection API would be disabled, then almost all of our problems would be solved (but a large part of the Java 7 API would no longer work).

Has Java always been this insecure? or is it really going downhill because it was acquired by Oracle?

Every programming language and computer architecture are insecure in some way. There is not such thing as "secure" in the Computer world, just "more secure". What hurts Java (and Flash before it, as well as Windows and now Mac) is that it is widely used and popular, not that it is any less secure than other languages out there. And that's the point, whatever OS, Language, technology is the most popular is going to get attacked much more than anything else and like all security, there are only two ways to be rid of it completely on a system (and even then it can still be bypassed):

Closed System a la iOS (meaning only programs that the OS maker approves can be installed - which is bad overall b/c it takes the choice/control out of our hands)

Stop using Java - which will lead to attacks on whatever is the most popular next.

I think Java's implementation of a security model is flawed. Instead of manually checking the call stack everywhere in the library that something insecure could be done, which is trying to secure a huge surface area, there should be a version of the library that simply doesn't have the potentially insecure functionality. For example, it shouldn't have file IO classes. What you can do in the browser should be limited to pure in-memory functionality and graphics functionality, and possibly a small amount of other benign stuff. The library would have to be factored in a way to make this division possible, and at this point dependencies are so entangled that it isn't remotely possible. But at least it can serve as a lesson learned for future languages.

I've heard the rumor that large numbers of Java developers at Sun quit rather than work for Oracle. Any truth to this?

Absolutely true. Sun's engineering talent abandoned ship in droves - if not immediately then after working under Oracle for a while. Some stayed for various practical or personal reasons but they all hate Oracle it seems.

I work in an office park that was built by Sun; the parts they personally used are now occupied by Oracle. When I go to the cafeteria, I sometimes see this gray-haired skinny old man, the very picture of a Unix computer scientist, who wears a faded Sun badge over his Oracle one. I'm not sure if I should feel sorry for him for living in the past or give him a thumbs-up for sticking it to the man.

I think Java's implementation of a security model is flawed. Instead of manually checking the call stack everywhere in the library that something insecure could be done, which is trying to secure a huge surface area, there should be a version of the library that simply doesn't have the potentially insecure functionality. For example, it shouldn't have file IO classes. What you can do in the browser should be limited to pure in-memory functionality and graphics functionality, and possibly a small amount of other benign stuff. The library would have to be factored in a way to make this division possible, and at this point dependencies are so entangled that it isn't remotely possible. But at least it can serve as a lesson learned for future languages.

The problem here is using the Reflection API to be able to access your system at a higher privilege level than what should be allowed and since that is ingrained into the JVM quite tightly, getting rid of Reflection would be nontrivial and make Java very dismal. What you need to do is have a flag set in memory that can't be written to from bytecode but read from that determines the permissions allowed on certain things. Sure, you could be able to buffer overflow and be able to overwrite said flag or code ahead of what is executing, but if you don't allow applets to be able to use JNI or JNA, you win because the buffer overflow cannot happen. Maybe it could in Java, but that is JVM-dependent and impractical for crackers. Look at the .NET security model (esp. for Windows Forms in IE). Not advocating IE here, but it is a good model.

I've heard the rumor that large numbers of Java developers at Sun quit rather than work for Oracle. Any truth to this?

Absolutely true. Sun's engineering talent abandoned ship in droves - if not immediately then after working under Oracle for a while. Some stayed for various practical or personal reasons but they all hate Oracle it seems.

What hurts Java (and Flash before it, as well as Windows and now Mac) is that it is widely used and popular, not that it is any less secure than other languages out there.

This is not true. The domain of the language certainly effects how secure it is. Javascript, for instance, is inherently more secure than C because it has no direct memory access, is executed directly from source (so you can't run code that wouldn't parse), and is completely sand-boxed with in your browser.

Javascript is widely used and popular. A hell of a lot more Javascript executes on my devices than Java, but it is not a vector for attack because of the inherent domain of the language.

I think Java's implementation of a security model is flawed. Instead of manually checking the call stack everywhere in the library that something insecure could be done, which is trying to secure a huge surface area, there should be a version of the library that simply doesn't have the potentially insecure functionality. For example, it shouldn't have file IO classes. What you can do in the browser should be limited to pure in-memory functionality and graphics functionality, and possibly a small amount of other benign stuff. The library would have to be factored in a way to make this division possible, and at this point dependencies are so entangled that it isn't remotely possible. But at least it can serve as a lesson learned for future languages.

The problem here is using the Reflection API to be able to access your system at a higher privilege level than what should be allowed and since that is ingrained into the JVM quite tightly, getting rid of Reflection would be nontrivial and make Java very dismal. What you need to do is have a flag set in memory that can't be written to from bytecode but read from that determines the permissions allowed on certain things. Sure, you could be able to buffer overflow and be able to overwrite said flag or code ahead of what is executing, but if you don't allow applets to be able to use JNI or JNA, you win because the buffer overflow cannot happen. Maybe it could in Java, but that is JVM-dependent and impractical for crackers. Look at the .NET security model (esp. for Windows Forms in IE). Not advocating IE here, but it is a good model.

This issue is not JNI, it's getting a classloader.

As usual, this is only an issue because of the browser plugin. Java (when broken) is as insecure as any language. The problem is most people don't download and run code in any language, they do it in Java in the form of applets. Because of the context in which it is run, there has to be a higher expectation of security for Java.

Get rid of the browser plugin, and its just another language, and just another runtime.

What hurts Java (and Flash before it, as well as Windows and now Mac) is that it is widely used and popular, not that it is any less secure than other languages out there.

This is not true. The domain of the language certainly effects how secure it is. Javascript, for instance, is inherently more secure than C because it has no direct memory access, is executed directly from source (so you can't run code that wouldn't parse), and is completely sand-boxed with in your browser.

Javascript is widely used and popular. A hell of a lot more Javascript executes on my devices than Java, but it is not a vector for attack because of the inherent domain of the language.

Lots of stuff goes down in your browser, like credit card transactions. Some malicious JavaScript can steal enough of your information to really hurt you fiscally and emotionally.

Your definition of secure needs to be changed. Sure, C has its issues, but that is because C was developed at a time where you needed DMA to access hardware and needed its speed due to its relative closeness to the metal because C is used for systems development and software programming (like your JavaScript implementation). In JavaScript, you don't hear of stack overflow issues because you don't have bounded buffers that can be overflown, but it can, in fact, be less secure than C.

It really all depends on the coder and how well said coder designs his application.

Didn't say it was. Used as an example of what you can block with non-writable flags.

Quote:

As usual, this is only an issue because of the browser plugin. Java (when broken) is as insecure as any language. The problem is most people don't download and run code in any language, they do it in Java in the form of applets. Because of the context in which it is run, there has to be a higher expectation of security for Java.

Get rid of the browser plugin, and its just another language, and just another runtime.

True on the language security part, but the guy (or guys) who developed the applet runtime probably should've done some things different because their design allowed for these problems to happen.

It really all depends on the coder and how well said coder designs his application.

Another thing that really hurts Java is that it doesn't utilize security features of operating systems very well. This may come about because of a need to be cross platform. There's also large, predictable, user writable blocks of memory in the JRE process. This makes it very easy to exploit without the need for heapspraying. Effectively you have an easy method of staging a payload, and then returning to that payload due to the architecture of JRE. Then all you need is a bug to exploit (of which there are many in the Reflection APIs).

This is another area where .NET is a lot more secure, there's no easily addressed, security opted out, memory blocks.