Slashdot Mirror


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

32 of 309 comments (clear)

  1. Java still there by Pieroxy · · Score: 2, 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.

    1. Re:Java still there by Anonymous Coward · · 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

    2. Re:Java still there by LWATCDR · · 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.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    3. Re:Java still there by egamma · · Score: 2

      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.

    4. Re:Java still there by DrXym · · Score: 2
      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 work with Oracle to produce a fix for the Java plugin.

    5. Re:Java still there by Creepy · · 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.

    6. Re:Java still there by jmrives · · Score: 2

      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.

    7. Re:Java still there by MightyMartian · · Score: 4, Insightful

      1999 called and wants their anti-Java rant back.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    8. Re:Java still there by 0123456 · · Score: 2

      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.

    9. Re:Java still there by petermgreen · · Score: 2

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    10. Re:Java still there by radish · · Score: 4, 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.

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    11. Re:Java still there by billDCat · · Score: 2

      Flash/Flex can handle complex applications just fine. Here are some examples of applications done with Flex: http://flex.org/showcase.php

      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 Java's capabilities, and I think it's easier to develop for and has a better experience installing and running on the client.

      That said, we are currently trending away from using plugins at all, due to the mobile platform. More and more will be done with HTML/JavaScript/CSS, leaving plugin-based tools as more niche products for Web development. Flex however now compiles mobile applications, so I think we will see more life in that space.

  2. warning? by Anonymous Coward · · 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.

  3. Won't help by ArsenneLupin · · Score: 2
    Couldn't the same exploit be run withing a plain (hidden) auto-refresh frame containing an 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...

    1. Re:Won't help by jlebar · · 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/.

    2. Re:Won't help by BattleApple · · Score: 3

      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.

  4. Stop trying to make the browser more than it is. by Anonymous Coward · · 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 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.

  5. Re:Stop trying to make the browser more than it is by Lisandro · · 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?

  6. Re:Totally overblown. by Hatta · · Score: 2

    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!
  7. Re:Stop trying to make the browser more than it is by dingen · · Score: 2

    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.
  8. Mozilla Craziness by Anonymous Coward · · 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.

  9. Further decrease market share by Fujisawa+Sensei · · Score: 3

    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.
  10. Umm... Flash? by Tridus · · Score: 4, 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.

    --
    -- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
    1. Re:Umm... Flash? by dveditz · · Score: 2

      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.

  11. Not blocked, but click to play by kangsterizer · · 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.

  12. The first applet is slower by tepples · · Score: 2

    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.

  13. SSL man in the middle by tepples · · Score: 2

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

  14. The problem is not Java by nweaver · · Score: 4, 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.

    --
    Test your net with Netalyzr
    1. Re:The problem is not Java by Bovius · · Score: 2

      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.

      What really shocks me is that this is the lead developers of Firefox recommending this solution. I just kind of assumed they would address the SSL/TLS issue instead of the particular implementation flavor the researchers chose.

    2. Re:The problem is not Java by bill_mcgonigle · · Score: 2

      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.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  15. Protection is already available by geekprime · · Score: 3, Informative

    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

  16. Re:Say what! by dveditz · · Score: 2

    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.