Java flaw allows “complete” bypass of security sandbox

http://arstechnica.com/security/2012/09/yet-another-java-flaw-allows-complete-bypass-of-security-sandbox/

by scottfr • 14 years ago

130 53 14 years ago

foohbarbaz2• 14 years ago

Another browser plugin hole? Yawn. It's disabled in Firefox and Chrome anyway. Let them disable it for good and enable by exception.

Who uses Java in browser anyway? WebEx and some weird VPN solutions?

ComputerGuru2• 14 years ago

And - get this - banks.

Chase requires Java to see pending Checks for business banking w/ fraud protection which lets you OK or reject checks before they're detected from your account.

Whereas they have scanned JPEGs for account history check images, the pending fraud control check images require Java.

bennysaurus• 14 years ago

Some banks are researching into extending that functionality too - creating effectively a disposable browser inside your browser to help mitigate against keylogging and screenshotting account details.

dools• 14 years ago

What's more surprising: banks using Java in the browser or people using cheques in 2012!

vibrunazo• 14 years ago

My bank does that to. I can only make online payments on my bank website if I install a browser java applet they call an "anti-virus". I stopped using it when they did it.

huxley• 14 years ago

Amazon uses it in the S3 dashboard for their "Enhanced Uploader (BETA)"

vitno• 14 years ago

all of the damn physics simulations out there... I'm taking a physics course right now...

shinratdr• 14 years ago

Any 10+ year old web applications (then called 'applets') that wanted to avoid the single browser nature of ActiveX or the mediocre performance of Flash.

pilif• 14 years ago

We used it to read bar codes from connected barcode scanners. It worked fine since 2004 but with all the security issues around, I developed another solution this summer which doesn't rely on Java.

Of course in the Enterprise where about 50% of our end-users are, it's still easier to tell them that they should install Java rather than something they don't know.

Which leads to us having to support both methods.

ttt_• 14 years ago

Do you mind elaborating a bit on your solution that doesn't rely on Java?

We have a similar case though with printers.

anodari• 14 years ago

Whenever we need to access some hardware (printers, smart cards, cameras, automate file updloads and downloads) we have to rely on a Java applet or Flash. The user must agree to the Java security warning before. Until browsers don't give us a better multi-browser and multi-plataform solution, we still need to use Java. Some of the html5 specs are to solve these issues.

brown9-22• 14 years ago

The actual announcement: http://seclists.org/fulldisclosure/2012/Sep/170

chuppo2• 14 years ago

I like the guy who responded to that with "Full disclosure? This is touching yourself in public."

And for sure it is, on a fulldisclosure list, nothing is revealed. My monocle dropped in my morning Java.

majke• 14 years ago

The "guy" is Chris Evans. He works at Google in Chrome Security Team.

* http://scarybeastsecurity.blogspot.co.uk/ * http://www.scary.beasts.org/security/

dmoo• 14 years ago

also of VSFTPD fame

blinkingled2• 14 years ago

It almost sounds like Oracle managed to shoo away all good folks from the JVM team and all they are left with is a bunch of B players. I dont remember it being this bad.

brown9-22• 14 years ago

If the vulnerability exists in Java 5, 6 and 7, it seems likely that the underlying problem is pretty old and not a recent development. Version 1.5.0_22 seems to have been released some time around 2009, and that was the end-of-life release for "Java 5" - it's earlier versions were years before this.

blinkingled2• 14 years ago

Good point - but still, isn't it taking Oracle longer to patch the vulnerabilities? (Last one they knew for what - 4 months?)

stephen2• 14 years ago

Given what I've seen lately, this is just false. The Java team under Oracle, despite my trollish expectations, is actually doing really well.

That they've inherited a huge, complex codebase is unfortunate.

I think any program or VM, Ruby, Flash, Python, whatever would end up with the same number of security holes if it had the user base to attract attention from hackers.

void-star• 14 years ago

Not to diminish your point about Oracle's handling of their inherited codebase (too much). I kindof agree...

But, it bears mentioning that Ruby and Python aren't a mainstream part of browsers. And Flash (under Adobe) has actually done some pretty impressive stuff recently with regard to sandboxing.

boyter2• 14 years ago

This isn't that surprising really. Microsoft's focus on security 10 or so years ago has paid off and its hard to find flaws in their OS now. The next most common platform is probably the JVM so its the new attack vector.

I would imagine we are going to see more and more of these exploits unless Oracle takes the same approach that Microsoft took, and even then it will be years before the benefits are felt.

hakaaak• 14 years ago

While it's possible that Java just hasn't been as much of a target, the difference between Windows and IE (which are the two M$ products that particularly got them into trouble with security flaws) and Java's JVM, other than one being an OS, one being a browser, and the other being a runtime environment, is that the former two started off being buggy and got better, and the JVM has been in the news for more security problems since Oracle took over. I think the finger to point is at Oracle. From what I have heard about how things went when they were taking over, I think the issue is that they are too "enterprise" for their own good. Sun's lawyers were pretty awful (or too good depending on whether you like suing) too though, so maybe some was inherited.

One other thing before I go- are other JVM languages affected by these bugs?

daeken2• 14 years ago

First, this bug existed at least for a year before Oracle acquired Sun. Same with almost all the other bugs that have plagued the JVM in recent years. I don't think pointing the finger at Oracle is worthwhile here.

Second, the parent wasn't comparing the products but the security practices followed; MS's hardcore security practices are well known and have served them very well over the last decade. The products they make have little to nothing to do with this.

Lastly, the language you use has absolutely nothing to do with this bug -- it's a JVM bug itself.

foohbarbaz2• 14 years ago

In a sense none of the "JVM languages" are affected: apparently it's a bug in the Web applets sandbox implementation. It's not something used by standalone Java (or whatever) programs. It only matters if you are running Java applets off a web page.

stephen2• 14 years ago

So, if MS is doing so well, why didn't this exploit stop at the Java process level?

(Not trying to rag on MS.)

daeken2• 14 years ago

The attack did stop at the Java process level. But once you're into that, you have the same privileges as anything else the user is running, by design. That's the same model taken by, well, every other OS out there effectively; it's not a problem as long as long as you have a separation of user account levels.

boyter2• 14 years ago

Unable to comment intelligently on this, I am not familiar with the exploit. I can only comment on the fact that Microsoft has spent a huge chunk of cash and time fixing their code. Most exploits on the Windows side are from applications running on it these days.

Taking a guess I would imagine its because the JVM is doing something it shouldn't be, similar to how Adobe products continually have flaws found in them, which isn't the fault of the OS.

If that's the case blaming Microsoft would be like blaming the Linux kernel for being exploited when the actual attack was against a service like Apache running under the root account. Unless you intelligently run things under proper accounts all the OS security in the world won't save you if there is a flaw in something running on it.

biot• 14 years ago

From the fine article:

  the flaw would be exploitable on any machine with Java 5,
  6, or 7 enabled (whether it’s Windows 7 64-bit, Mac OS X,
  Linux, or Solaris
  [...]
  “An attacker could then install programs, view, change,
  or delete data with the privileges of a logged-on user.”

In short, you can rag on modern operating system design because whatever permissions you grant to the Java process (regardless of operating system) are the same permissions which get inherited by the exploit. If you run the Java process under sudo on Linux, then the exploit runs under sudo as well.

snambi• 14 years ago

who runs java in browser these days?

SageRaven• 14 years ago

Anyone who manages hardware via remote console, such as Dell's iDRAC. HP and and Fujitsu have similar systems, and I imagine many more.

It's a major pain in the ass, and it sucks, but it's true.

jermy• 14 years ago

Supermicro's equivalent IPMI remote access (iKVM) is also Java

marvin• 14 years ago

Every Norwegian internet banking customer, for instance.

unabridged• 14 years ago

Java (and flash) should only be ran inside a virtual machine. You have to be a fool to have that installed on your bare computer.

iso8859-1• 14 years ago

So you're saying that I shouldn't compile my Java code with GCJ and execute it? Hardly anyone is doing that.

finnw• 14 years ago

I think he meant VM as in emulator (e.g. vmware), not as in the Java runtime.

Java flaw allows “complete” bypass of security sandbox

Related Stories