To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework
rastos1 writes with this news from The Register: "In a demonstration last Friday, it took less than two minutes for researchers Thai Duong and Juliano Rizzo to wield the exploit to recover an encrypted authentication cookie used to access a PayPal user account. ... The researchers settled on a Java applet as their means to bypass SOP, leading Firefox developers to discuss blocking the framework in a future version of the browser. ... 'I recommend that we blocklist all versions of the Java Plugin,' Firefox developer Brian Smith wrote on Tuesday in a discussion on Mozilla's online bug forum. 'My understanding is that Oracle may or may not be aware of the details of the same-origin exploit. As of now, we have no ETA for a fix for the Java plugin.'"
I have to say I am actually surprised to see how many people still have a Java plugin for their browsers. I had a look at the analytics of my website and it looks like more than 80% of my visitors have one.
I heavily use Java on the desktop (Eclipse, etc) and on my servers (Tomcat) but I thought Java Applets to be dead for long.
Write boring code, not shiny code!
How about a simple warning before loading a Java Applet? For example, one of those yellow bars at the top of the page? That would prevent all legitimate applets from being instantly unusable in Firefox, whilst providing some security.
Indeed, image doesn't enforce "same origin" either, and the server (of the frame) can stil introduce the needed padding into the URL...
Web browsers are good for viewing static documents, especially ones that link to other static documents.
Time and time and time again, however, they have been shown to be horrible at hosting more complex applications and interactive functionality.
It doesn't matter which embeddable application technology we consider, they are all rife with security flaws. Java applets, ActiveX controls, JavaScript, Flash, and browser plugins (like PDF viewers) have all suffered from numerous security problems.
If you need to provide your users with application-like behavior, then just write a native application!
Browsers are not operating systems. They are not good at hosting applications in a secure manner. Even after two decades of trying, they still aren't suitable environments for hosting applications. It's looking like they never will be, either.
You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?
The attacker must be a man-in-the-middle and control a website that you visit in order to have any chance of getting a cookie/password/thing-of-value that it must already be able to guess.
Why is that so implausible? With high profile sites like kernel.org, linux.com, mysql.com being compromised on what seems like a biweekly basis these days, I wouldn't put that out of the realm of plausibility.
Give me Classic Slashdot or give me death!
If you need to provide your users with application-like behavior, then just write a native application!
When there was just one popular platform to run these native applications on, this was a fine solution. I mean back when everybody did everything in Windows. But nowadays, people are using all sorts of systems. Not just Mac OS X and Linux on the desktop, but iOS, Android, Windows Phone, BlackberryOS and Symbian on mobile devices as well. So "just write a native applications" actually becomes "write a native applications and then port it to 7 other platforms". That's when a web application suddenly starts to look like a viable alternative.
Pretty good is actually pretty bad.
What is with all of the over-the-top craziness coming out of Mozilla recently? Oracle needs to address the bug, but maybe Firefox could handle it in a more graceful manner than disabling the plugin entirely.
Mozilla, you used to be one of the darlings of open source, now you're turning into a crazy cat lady.
- remove version numbers.
- rapid release schedule breaks add-ons.
- gave the middle finger to enterprise users.
- removed the URL bar.
Way to further decrease market share. First start fuck with the versions numbering. Now blacklist java.
Keep taking the express elevator to the bottom, just like Netscape did.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
So they want to block Java over what is a difficult to execute attack that has some serious requirements to even use... but they continue to allow Flash with it's critical flaw of the week that's being actively exploited?
Is this a joke? Flash is the single largest attack vector on the entire fucking Internet.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Quoting decoder from the security team:
"It should be "click to play" by default, which means you have to click on the applet for it to be activated and loaded. "Disabled" might have been the wrong term here, but until you click the applet, nothing can happen."
That's what Chrome does also. Then again in theory, flash should also be click to play. Except flash is used everywhere and its going to piss people off, so its not click to play, either in Chrome. In fact, all plugins should be click to play with a white list of auto play sites that the user can configure. Yeah, Noscript.
Still, I'd prefer default click to play in java.
Java is slow for the first applet you view in a browser session. After that, the important class libraries are already in RAM, and further applets load just as fast as, say, SWF objects.
The attacker must be a man-in-the-middle
The server's ISP is a man-in-the-middle. The operator of a national firewall is a man-in-the-middle. This is not unlike what Perspectives calls the "Lserver attack".
The problem is NOT java, the problem is SSL/TLS. Java was just the vector which was used to exploit this, and disabling Java doesn't disable the real problem, especially since Mozilla refuses to support TLS 1.1.
Its also unclear in the press how the Java same origin bypass worked for this test: Was it click to install or a real flaw? As a tool author (Netalyzr [berkeley.edu]), being able to bypass same origin without a signature dialog would be a big deal in improving the quality of our tool.
Test your net with Netalyzr
I have been using noscript http://noscript.net/ for years. Paste from thier page,
----------------------
The NoScript Firefox extension provides extra protection for Firefox, Seamonkey and other mozilla-based browsers: this free, open source add-on allows JavaScript, Java and Flash and other plugins to be executed only by trusted web sites of your choice (e.g. your online bank), and provides the most powerful Anti-XSS protection available in a browser.
NoScript's unique whitelist based pre-emptive script blocking approach prevents exploitation of security vulnerabilities (known and even not known yet!) with no loss of functionality...
You can enable JavaScript, Java and plugin execution for sites you trust with a simple left-click on the NoScript status bar icon (look at the picture), or using the contextual menu, for easier operation in popup statusbar-less windows.
----------------------
I have always thought that a white list approach was the best for anything as powerful as java & javascript, either one is essentially running someone else's unknown programs on your machine there may be a "sandbox" now but I really don't know how secure that is either
Mozilla is working on a short-term patch to TLS that will prevent the attack in the browser (see the bug), and in the longer term will implement TLS 1.2 (but if you don't prevent TLS downgrades you haven't fixed anything, and if you do you break all the version-intolerant servers out there).
No browser fix can prevent this attack from using a vulnerable plugin such as Java since Java is making these network requests on its own. Either the plugin vendor issues a fix, or you fix it by disabling the plugin.