To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework 309
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.'"
Java still there (Score:3, Informative)
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.
Re:Java still there (Score:5, Informative)
I know no one rtfa but thearticle gives plenty of examples of webapps that rely on Java. Loads of corporate apps rely on it. I think that this is a bad move without a whitelist being released in tandem,which they are considering
Re: (Score:2)
I know IE/ActiveX supports trust levels for remote code. (I.e. "I don't want these users running ActiveX code from anything but the trusted servers on our intranet"). Does Java have similar capabilities?
Re: (Score:3)
In the meantime they can wo
Re: (Score:2)
The problem here is that both Firefox and OpenSSL lack support for TLSv1.1 and 1.2. That needs to be addressed before planning to remove SSL3/TLSv1.0 support. In the short-term, the Chrome/OpenSSL fix will hopefully work well enough, and IE9/Opera can disable TLSv1.0 now if you really want.
Re:Java still there (Score:5, Interesting)
Why?
Java is a much nicer development system than say Flash.
Frankly Java applets got a bad rap because of Java abuse. I blame Microsoft for that. You see FrontPage had animated buttons as an option and they where freaking java applets.
No one should have to wait for java just for buttons.
It is a shame that applets have gotten such a bad rep. It is an even bigger shame that Apple and Google are not supporting Java on IOS, Android, and Chrome.
Re: (Score:2, Interesting)
Back in the days, I was impressed by HotJava. This was a full blown web browser developed in Java. No Javascript. It worked well and, as expected, ran Java Applets natively.
I still don't know why they dropped the development...
Re: (Score:2)
My guess is there wasn't a way to take advantage of NPAPI. ie. You had to write native Java apps to integrate other types of content.
Re: (Score:2)
Well... they stopped the project once it was up. Their goal was to demonstrate the Java technology, not to make a web browser as a sustained product.
Yes plugins were Java based of course, but I'm sure that could have worked. But let me tell you, by 200, we (linux & non windows users) were in sore need for a web browser. A Java-based one would have done it ;-)
Re: (Score:3)
No one should have to wait for java just for buttons.
People don't like to wait, period. Java is slow, at least on Windows, and I suspect any platform other than Solaris.
The first applet is slower (Score:3)
Re: (Score:2)
Which means that Java is no longer slow by then. Only the rest of your system :)
Re: (Score:2)
Not any more. Really that is one of those myths that will never die. On a modern system Java will load up pretty dang fast. The browsers could also have an option to preload in the background using a thread if enough people where using Java to make it worth while.
Re: (Score:2)
Not any more. Really that is one of those myths that will never die. On a modern system Java will load up pretty dang fast. The browsers could also have an option to preload in the background using a thread if enough people where using Java to make it worth while.
I have a perfectly modern computer. I use HP Sitescope, which has a web interface. Version 9.5 is HTML based--and it's fast, even on a 5 year old 32 bit system. Click a link and the page loads in a quarter-second. I just installed Version 11.11, on a newer, 64 bit system. Version 11 has a java interface, and is takes 3 seconds to load each page--and it's must slower if I'm working remotely, instead of sitting in the same building. And I'm not counting the start-up time.
My explanation? Java is slower than
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Aside from that I doubt you'd even know what language an app was running in unless you went poking around in its directory, or the app gave itself away (e.g. by using metal theme).
The multi-second garbage collections and multi-gigabyte memory usage for a text editor tends to be a pretty good indication of a Java app.
Re:Java still there (Score:5, Insightful)
I work professionally with a mixture of IntelliJ, Eclipse and Visual Studio on a decent spec machine. One of those three performs more slowly and chews up more resources than the other two. I'll give you a hint - it's the one which isn't written in Java.
Not only is Eclipse slightly more than a "text editor" it also performs significantly better than a less-featured IDE written in a supposedly faster language. The "Java is slow" BS has to stop, it hasn't been true for close to a decade now.
Re:Java still there (Score:5, Insightful)
1999 called and wants their anti-Java rant back.
Re: (Score:2)
Why? Java is a much nicer development system than say Flash.
Really? I do a lot of desktop and server java, but not much applet development. It's not great, and I expect that if you want to do animations, music and that, there are better tools for producing flash versions.
Re: (Score:2)
Re: (Score:3)
How can you even compare Flash and Java?
For those trying to develop apps in a web browser that don't fit the traditional page by page model there are essentially 4 choices.
1: AJAX
2: Java applet
3: FLASH
4: Activex control
So of course those choices will get compared. They all have strengths and weaknesses of course but they can be used for much the same tasks.
Re: (Score:3)
Flash/Flex can handle complex applications just fine. Here are some examples of applications done with Flex: http://flex.org/showcase.php [flex.org]
In there is a timeline-based video editor, a calendaring/email/finance app, a task manager, and a photo editor. I've also seen a PowerPoint type presentation app, a Visio-type tool for creating object relationship charts, plus I've used it myself for creating a medical reporting application for diagnostic sensor data analysis. Flex can hold it's own very nicely against Jav
Re: (Score:2)
Legacy Systems tend to have a Java Applet to "Web Base" their applications... Mostly because these apps were webified back in the early 2000's where HTML was quite limited, as well the fact that HTML disconnects makes it rather impractical or at least a demanding job to interface with those old telnet/terminal application. That don't disconnect after each request. Being that Java was supposed to be cross platform it was a better choice then choosing ActiveX.
Then there are those Java Applet Games that stuck
Re: (Score:2)
Java plugins are distributed via the JRE and could also be delivered by 1 click as a plugin when needed by a website. It's quite conceivable that someone doesn't even know it's installed. I just looked and not only do I have it installed but it's the most up to date version too.
Plus my Mozilla has something called the Windows Live Photo Gallery, whatever that is. I certainly don't remember installing anything like that.
Re: (Score:2)
I still have an antique printer (HPLJ2100) and the management console uses Java applets.
Re: (Score:2)
Re: (Score:2)
Your average Web user will install ANYTHING if they want to view a website or if some banner ad promises them some "cool" thing. They'll just blindly bomb that OK button like a trained hamster pushing the button to get a pellet. (That's not a bad simile.) Seriously, you could title it "Spy Formatter Pro" and they would install it, because they wouldn't even read the title.
Then once installed, it's out of sight, out of mind - the idea that "this plugin is going to stick around after I close this website" is
How to prove one has the smarts to know better? (Score:2)
we have to make sure there are safeguards in place like [...] maybe requiring approval for plugin installation from someone with the smarts to know better than to install [a trojan disguised as a video player component]
So how would a more knowledgeable PC owner prove he has "the smarts to know better" in order to approve a plugin installation?
Re: (Score:2)
Re: (Score:2)
Your average Web user will install ANYTHING if they want to view a website or if some banner ad promises them some "cool" thing
I've been looking at tick based web games recently. A surprising number of them want to install exe files. I can't run an exe file, but I wouldn't dl and run it even if I could. May as well throw security and privacy right out the window.
AFAICT none of these games NEED to run an exe on your puter.
I'm sure I'm the exception, not the rule.
Re: (Score:2)
My college uses Blackboard, and the only way to upload files from the computer is via the Java plugin (odd since a school I went to before didn't need it to upload, unless more recent versions of blackboard added it.) Once I'm done with needing it, I do plan on getting rid of it. It's another plugin I don't really care for.
Re: (Score:2)
Also, VPN portals..
Re:Java still there (Score:5, Interesting)
Java plugin based internet apps for enterprise are very common, especially in the CAD/CAM/CAE space because they can run on multiple platforms and some of those spaces are heavily entrenched in UNIX (with a trend toward Linux UNIX-like), and many of those depend on Firefox for cross platform support.
Re: (Score:2)
... and DRAC remote console on any Dell server among many other things.
You can infer a lot from the "Java is dead" crowd, like they probably don't have a job in IT, or they don't use UNIX, like to say things are dead a lot, etc.
Re: (Score:2)
I play too, but I disabled the browser plugin after installing Java. That's the thing - you can't JUST install the JRE, which would be a lot safer. You always get the browser plugin no matter what.
Re: (Score:2)
Nope, pretty much all board game apps require Java, many bank websites, etc require this. I'm not saying they should, just saying they do.
That may change in the near future. In my area, applets are often used for simple chemical structure editors, but there are some commercial and free/open-source javascript solutions for this. Even 3D molecular viewers, like twirlymol:
http://baoilleach.blogspot.com/2009/01/twistymol-is-dead-long-live-twirlymol.html [blogspot.com]
There are many advantages, such as better page integration, no startup time, no "install java" popup, etc.
Re: (Score:2)
Ooh. For an impressive commercial option, consider 3D zeolites with WebGL :
http://web.chemdoodle.com/demos/iza-zeolite-explorer [chemdoodle.com]
(May require ffx or chrome, doesn't load in safari)
warning? (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Won't help (Score:3)
Indeed, image doesn't enforce "same origin" either, and the server (of the frame) can stil introduce the needed padding into the URL...
Re: (Score:2)
I haven't read up too closely on this, but I think traffic going through Firefox itself is not vulnerable. See http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/ [mozilla.com].
Re: (Score:2)
Doesn't that pretty much perfectly describe everything Mozilla's been doing in the last 6 months?
Re: (Score:2)
Quickly, we need to block tags too! As a matter of fact, shut down the whole browsing feature! It's just a liability anyway.
Unplug the computer, it's the only way to be sure!
Re:Won't help (Score:4)
Just like if you handcuff everyone to their beds, there will be no more crime.
There's still a chance some of them would rip off that label on their mattress.
That is a monsterous solution (Score:2)
...and will further put a stake into the heart of Java in the web.
Re: (Score:2)
Actually I think it would put a stake into Mozilla based browsers, because if they block Java plug in today, how do you know what they will do to the browser tomorrow?
AFAIC if they go this road, they are dead as a browser.
Stop trying to make the browser more than it is. (Score:2, Interesting)
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 p
Re: (Score:3)
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?
Re: (Score:2)
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 only flaw with HTTP is that it is stateless. It is also its greatest strength.
I'd hardly call cookies 'number of kludges and patches' though. Ah, here is the RFC: http://www.ietf.org/rfc/rfc2109.txt [ietf.org]
Re: (Score:2)
Thanks for the RFC reference. Cookies are perhaps the most painless aspect of "modern" HTTP dev work; i was aiming more at atrocities like AJAX.
Re: (Score:2)
Ajax conforms to the HTTP protocol pretty much like everything else. It is an http request sent by the browser basically indistinguishable from another regular http request to get an image or an html file. Nothing was done in the HTTP protocol for AJAX. What are you talking about exactly?
Re: (Score:2)
Re: (Score:2)
But this is just a lack of optimization on the part of the browsers... It'll come in time. But it is not an "atrocity" like the GP was saying...
Re: (Score:2)
No. The parent poster raises a nice point regarding TCP sockets and how they're handled to provide "instant" UI response. Google does it beautifuly but it requires a crapload of work and testing in order to get it right, not to mention it basically (again!) abuses a TCP feature intended for a completely different thing.
Re: (Score:2)
But there are simple solutions for that problem. The fact that Chrome abuses some TCP feature is a Chrome problem, not an AJAX one. Nothing prevents a browser to set a keep alive in the HTTP headers and let a socket open to the server. This is an existing feature of HTTP, respect perfectly TCP, and was even designed for that very purpose !
I have to say I'm not familiar with that specific subject, but I fail to see a problem there.
Re: (Score:2)
The feature is abused by AJAX which depends on long TCP sessions. I mentioned Google because its online apps usually implement this very well (from the UI point of view, at least).
Re: (Score:2)
Not to mention the original poster wasn't talking about that at all. He finally answered and his grudge is against HTML and JavaScript... ;-)
Re: (Score:2)
I hate JS :), but that is beyond the point. Do you realize the amount of work and back-and-forths you need to do only to perform an action when you click on something on a page?
If it's about mistuned servers (Score:2)
Re: (Score:2)
I'm talking the fact that you need to execute an HTML call in scripting language inside the same browse to retrieve HTML content which most of the times requires a framework tool in order to be reprocessed and inserted into the main pages' DOM. It's a (very ugly) workaround for the fact that HTML is was designed as a one-way method of comunication - static content.
Re: (Score:2)
It all depends how you use AJAX I guess.
I use it to submit forms, so that I avoid the problem of having to refresh a page in which a user has made some input. In this regard, I save time and energy, and the user has a faster response. It's all a win.
I also use it to refresh some components in html pages. No DOM is needed there as it is as easily done by grabbing an HTML fragment from the AJAX request and putting wherever you need with the innerHTML attribute. Again, it saves bandwidth and time to code. Ano
Re: (Score:2)
Re: (Score:2)
Exactly - this is was i was talking about. A true full-duplex web protocol would be a godsend. Thanks!
Re: (Score:3)
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
Re: (Score:2)
Nowadays you have a lot of options to ease code porting - including the allmighty "write once, run everywhere" Java. Lately i've been working a lot with Python and i'm amazed of how painless it was to port apps between Windows and *nix (i.e, no pain at all).
Re: (Score:2)
Okay. Now try porting it to iOS. Or ChromeOS. Or WebOS. Or Blackberry.
I'm gonna bet WP7 and Android wouldn't be painless, either. And good luck getting people to install Python on their Windows box before they can even try your app.
Re: (Score:2)
PyObjC [sourceforge.net]. It's completely doable.
And even then, it is not the desired target. If you use the right tools for each platform it gets way easer; Java paves and easy road for porting between desktops, Android, iOS, Chrome and Blackberry, for example.
Application logic in which language? (Score:2)
So do the sensible thing and have several native implementations.
Ideally, these native implementations should be able to share the same application logic, just with a different front-end per platform. This way, if I fix a defect in the application logic, it's fixed across all ports. This is one advantage of separating model and view layers [pineight.com]. But apart from JavaScript in a web browser, is there a single programming language that can be used on Windows, Mac OS X, desktop Linux, iOS, Android, WebOS, ChromeOS, BlackBerry OS, and Windows Phone 7, in which to write this applica
Microsoft has ended support for J# (Score:2)
Re: (Score:2)
Agreed, but then again, there's no magical solution for porting. There are great tools that ease the process though, in pretty much any platform and technology you'd like.
The fact that porting requires work shouldn't be an excuse to turn web browsers into fancy VMs.
Re: (Score:2)
The fact that porting requires work shouldn't be an excuse to turn web browsers into fancy VMs.
Why not? Isn't it about getting your application to as many people as possible, with the least amount of effort?
Re: (Score:2)
So the solution to Nintendo pissing over homebrew developers is turn every single game into web apps?
Compare WiiCade (Score:2)
Re: (Score:2)
Meh. If your application is primarily presenting a UI then a web app isn't such a bad solution. For applications that actually do something, most of the work is behind the scenes. If it's Desktop only write it in Python or the like and you've suddenly got the entire desktop/notebook market finished. If you want it to run on a phone or tablet (and it SHOULDN'T run on both a phone and a desktop) then write it in C and slap Android and iOS UIs on it.
Re: (Score:2)
The difference is that even though people complain about a lack of compatibility between the browsers, the differences are in fact very minor when compared to the differences between operating systems.
The main concern are old browsers, they are a nuisance. Modern browsers behave surprisingly alike.
Re: (Score:2)
Web browsers are good for viewing static documents, especially ones that link to other static documents.
Yep, but in the past 10 years they've gotten damn good at other things too beside hosting a page with the blink tag. Frankly I don't miss the days of a static web page.
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.
The same could be said for nearly every application written in any other language. Security is something that needs to be applied from the ground up whether you're designing a database front end designed to run in a web browser or writing a simple native program in C.
Even after two decades of trying, they still aren't suitable environments for hosting applications. It's looking like they never will be, either.
Two decades of trying? Just when do you think Web2.0 actually took off? The
Re: (Score:2)
Re: (Score:2)
If you need to provide your users with application-like behavior, then just write a native application!
Give me a solid workaround for each of these problems and I'll agree with you:
Re: (Score:2)
That IS the problem with browsers. It's like allowing executable code in a data document - it's something that SHOULD be safe but isn't.
Spyware, too (Score:2)
Spyware/malware used to be much more of a pain because you had to download and trust a large number of applications to do much with your computer. Many user's needs are sandboxed into webapps these days, preventing a lot of issues.
Mozilla Craziness (Score:5, Insightful)
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.
Further decrease market share (Score:4)
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.
Umm... Flash? (Score:5, Insightful)
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.
Re: (Score:2)
Java isn't far behind, though, and it's rarely used for anything besides Runescape and the occasional application that was made before Flash was big. The danger here is that people have Java installed as a web plugin when it really, really doesn't need to be in most circumstances.
Re: (Score:2)
People use flash all the time. HTML 5 is on the way, but until it's issues (codecs, full screen, ads) are worked out flash is still the only common option for video on the web.
Java on the other hand, nobody cares about. Other than a few specialty applications or very old websites Java applets have long been dead.
Sun's early poor design decisions and the resulting horrible performance (nobody like their whole browser freezing for 30 seconds while an applet loads) killed it long ago. Modern Java has somewhat
Re: (Score:3)
If there were "better" ways that didn't require a plugin they would have demoed that. Maybe there are such ways, but not through simple <script> or <img> tags. In some ways I wish that is what they used: we could have fixed that ourselves rather than being at the mercy of plugin vendors.
Not blocked, but click to play (Score:5, Insightful)
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.
Re: (Score:2)
A large portion of their user base installs a flash blocker that allows them to decide if they want to view a flash file or not. I don't get why they don't pick up on these things. Having the functionality in the browser is great. Having the ability to make a decision is even better.
The problem is not Java (Score:5, Informative)
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.
Re: (Score:3)
Quick, somebody code up this exploit in Flash so Mozilla is forced to make the proper fixes, instead of blaming the kid they don't like.
I hope they don't over react (Score:2)
The reaction to XUL pages on the web was horrible, "just drop support". I hope they bring it back and warn the user about the dangers on a site by site basis with both instead of dropping support.
MozDev's can solve all problems (Score:2)
Alternatively, we can remove all banks.
See...problem solved.
Protection is already available (Score:4, Informative)
I have been using noscript http://noscript.net/ [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
Re: (Score:3)
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.
SSL man in the middle (Score:3)
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" [slashdot.org].
Re: (Score:2)
Something that can decrypt a cookie can just look at your cookies directly from your machine. If you install an evil Java pluggin it could decrypt and expose the content of your encrypted cookies without you knowing about it.
Re: (Score:2)
Disabling Java in IE9:
Tools->Manage Addons->Click Java Plugin->Select Disable from Menu
Re: (Score:3)
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.