Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Firefox Java Mozilla Security

To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework 309

Posted by timothy from the nuclear-option dept.
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.'"
This discussion has been archived. No new comments can be posted.

To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework More

To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework

Comments Filter:

  • Java still there (Score:3, Informative)

    by Pieroxy ( 222434 ) on Thursday September 29, 2011 @09:32AM (#37552910) Homepage

    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)

      by Anonymous Coward on Thursday September 29, 2011 @09:41AM (#37553034)

      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

      • 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)

        by DrXym ( 126579 )
        A better idea would be for Mozilla to take the approach Google are following and interfere with the exploit making it unlikely anyone would be attached to a site long enough for it to matter. They should (working in tandem with other browser vendors) give notice that SSL & TLS 1.0 are deprecated, that the protocols will be active for 12 months and then disabled thereafter and require a user to manually reenable them. That might put some pressure on sites to actually upgrade.

        In the meantime they can wo

        • 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)

      by LWATCDR ( 28044 ) on Thursday September 29, 2011 @09:49AM (#37553110) Homepage Journal

      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)

        by Pieroxy ( 222434 )

        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...

        • 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)

            by Pieroxy ( 222434 )

            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)

        by egamma ( 572162 )

        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.

        • 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.

        • Re: (Score:2)

          by LWATCDR ( 28044 )

          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)

            by egamma ( 572162 )

            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

        • That's what's wrong with kids these days. Back in my day we didn't have these fancy personal computers to compile code; we had to wait our turn with the one computer with our punch cards. And the punch cards at my school weren't those sissy paper ones. Ours were manly stone cards. If you made a mistake, you had to walk uphill both ways in the snow (even during summer!) to cut another one. If you were lucky, Chuck Norris would lend you his comb to cut the stone. If you weren't, you had to use your swin

        • Re: (Score:2)

          by DrXym ( 126579 )
          Java isn't slow. Like any runtime it has a startup cost. Once that's over with it works perfectly well for even large apps. Eclipse for example. 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).

          • Re: (Score:3)

            by 0123456 ( 636235 )

            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)

              by radish ( 98371 ) on Thursday September 29, 2011 @01:20PM (#37556002) Homepage

              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)

          by MightyMartian ( 840721 ) on Thursday September 29, 2011 @11:32AM (#37554496) Journal

          1999 called and wants their anti-Java rant back.

      • 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.

      • Just so that there is no confusion..., Google does support Java in a big way. Java is the development language for Android. They also provide Google Web Toolkit, which allows one to write browser side code in Java which then gets translated into HTML and Javascript. There are Eclipse plug-ins for both Android and GWT SDKs. I use them daily and I am very pleased with Googles support of Java and these software development kits.

    • 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

    • 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.

    • I still have an antique printer (HPLJ2100) and the management console uses Java applets.

    • 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

      • 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?

      • Pls, where can I find this "Free_Funny_Video_Spy_Malware_Trojan.exe" program? I would like to install it across all my machine networks, thx.

      • Re: (Score:2)

        by Tsingi ( 870990 )

        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.

    • 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.

  • warning? (Score:3, Insightful)

    by Anonymous Coward on Thursday September 29, 2011 @09:33AM (#37552916)

    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.

    • This. I wonder if there's some sort of Flashblock-like extension to do this. I would certainly prefer it. Unfortunately we actually have a very very important Java applet at work here that I have no real choice but to use.

  • Won't help (Score:3)

    by ArsenneLupin ( 766289 ) on Thursday September 29, 2011 @09:35AM (#37552948)
    Couldn't the same exploit be run withing a plain (hidden) auto-refresh frame containing an <img src="..."> tag pointing to the victim server?

    Indeed, image doesn't enforce "same origin" either, and the server (of the frame) can stil introduce the needed padding into the URL...

  • ...and will further put a stake into the heart of Java in the web.

    • 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)

    by Anonymous Coward

    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

    • 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)

        by Pieroxy ( 222434 )

        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]

        • 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)

            by Pieroxy ( 222434 )

            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?

            • He's probably talking about things like how the browser/web server create a new TCP session for each and every AJAX request, even if they're going to happen every few seconds for as long as you're on a page. Google gets around this by setting some silly-long keep-alive on the TCP connection for the original page request on pages like gmail so the first few AJAX requests at least don't take the extra overhead.

              • Re: (Score:2)

                by Pieroxy ( 222434 )

                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...

                • 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)

                    by Pieroxy ( 222434 )

                    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.

                    • 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)

                    by Pieroxy ( 222434 )

                    Not to mention the original poster wasn't talking about that at all. He finally answered and his grudge is against HTML and JavaScript... ;-)

                    • 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?

              • So it appears someone's core complaint about AJAX is that a lot of AJAX sites are run on mistuned servers whose default keep-alive time is too short for AJAX. If the problem is with the TCP keep-alive mechanism, wouldn't a connection-oriented protocol have exactly the same problem?

            • 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)

                by Pieroxy ( 222434 )

                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)

        by dingen ( 958134 )
        WebSocket [wikipedia.org] is developed to shine where HTTP fails. It's not yet ready for the masses, but Firefox 4, Opera, Chrome and Safari already have some support. WebSocket will make Ajax and polling in general a thing of the past, enabling even more application-like behaviour in your browser.

        • Exactly - this is was i was talking about. A true full-duplex web protocol would be a godsend. Thanks!

    • Re: (Score:3)

      by dingen ( 958134 )

      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

      • 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).

        • 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.

          • 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.

        • A Java application does not run on Windows Phone 7. Only web applications and applications written in verifiably type-safe .NET languages work on Windows Phone 7, and Microsoft has ended support for J# as far as I know. Python doesn't work on a lot of these more locked-down platforms either: it and other DLR languages require Reflection.Emit, which isn't present on a lot of the minimal CLRs. Nor will Java or Python help you get Sony or Nintendo to approve your application for execution on a PSP, PS3, PSVita

          • 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)

              by dingen ( 958134 )

              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)

        by ceoyoyo ( 59147 )

        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.

    • 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

      • Today's computing ecosystem is still to volatile to guarantee perfect security whether you build from the ground up or apply endless patches and updates. Look at the number of permutations of Operating Systems, OS Versions, OS Security Patch Levels, OS Bug Patch Levels,Hardware platforms, and custom Applications. It's amazing anything works or is even half way secure especially when you introduce user actions into the mix.

    • Re: (Score:2)

      by tepples ( 727027 )

      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:

      • Unlike native applications made for Windows, web applications work on Macintosh computers and PCs running Linux. (Workaround: Qt)
      • Unlike native applications made for PCs, web applications work on video game consoles and smartphones. (Workaround: ?)
      • Unlike native applications, web applications can be used by limited users who have no privileges to install applications on a machine. (Workaround: ?)

  • Mozilla Craziness (Score:5, Insightful)

    by Anonymous Coward on Thursday September 29, 2011 @09:59AM (#37553222)

    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)

    by Fujisawa Sensei ( 207127 ) on Thursday September 29, 2011 @10:01AM (#37553262) Journal

    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)

    by Tridus ( 79566 ) on Thursday September 29, 2011 @10:02AM (#37553288) Homepage

    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.

    • 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.

    • 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

  • Not blocked, but click to play (Score:5, Insightful)

    by kangsterizer ( 1698322 ) on Thursday September 29, 2011 @10:14AM (#37553452)

    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.

    • 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)

    by nweaver ( 113078 ) on Thursday September 29, 2011 @10:37AM (#37553772) Homepage

    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.

    • 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.

  • 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.

  • So, I propose a solution to the bank robbing problem. Let's seal all the doors and windows of every bank with 3" steal.

    Alternatively, we can remove all banks.

    See...problem solved.

  • Protection is already available (Score:4, Informative)

    by geekprime ( 969454 ) on Thursday September 29, 2011 @11:59AM (#37554862)

    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

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close