Slashdot Mirror


Java/Script Alert: Cross-Platform Browser Vulnerability

Ant writes "Synopsis: Opera, Mozilla & Netscape with javascript enabled are vulnerable to remote command execution. This has been tested on Microsoft, and many many Unices. Macintosh may also be vuln. Ironically enough, IE is unaffected." Update: 06/08 23:56 GMT by H : The problem seems to be one in the Java security model itself; but the evidence seems to be that if you turn off JavaScript, you turn off the vulnerability. Update: 06/09 00:56 GMT by T : According to this followup message from Mozilla security group member Daniel Veditz, the problem is actually one that's already been fixed in Mozilla 1.3, and not a remote command execution vulnerability at all. (Thanks to reader Jared Klett and others.)

21 of 314 comments (clear)

  1. Ex-Squeeze-Me?! by inertia187 · · Score: 4, Insightful

    I'm going to stick my neck out here and say, What.In.The.Hell? Who's the editor on-duty here, an Onion stand in?

    First of all, the example made is JavaScript, not Java. Second, the example shows how to bring up a page 23000 seconds after they left the page. Not good, but not new either. So what's the big deal?

    --
    A programmer is a machine for converting coffee into code.
  2. Obligatory rant by OmniVector · · Score: 5, Insightful


    Java is NOT THE SAME THING as JavaScript.

    Come on slashdot editors, it's not hard to know the difference (this is in reference to the article title).
    </rant>

    --
    - tristan
    1. Re:Obligatory rant by rasafras · · Score: 5, Funny

      Well, it seems I was wrong. Oops. The editors'll probably repost the article in a day or two anyway, maybe they'll fix it then.

  3. "Macintosh may also be vuln." by Anonymous Coward · · Score: 4, Funny

    If you can't be bothered to write out entire words, don't post articles to slashdot.

    It's not like you were tight on space there.

  4. WTF, over? by alecto · · Score: 4, Interesting

    WHAT, exactly does the Java security model have to do with JavaScript--an unfortunately named, but totally different, animal?!

    1. Re:WTF, over? by LostCluster · · Score: 4, Informative

      Simply put, a JavaScript is being used to call for a Java applet after the user has presumably left the page... the result is a Java applet that is permitted to run outside the usual sandbox, and there's your hole.

      Both are flawed...

    2. Re:WTF, over? by MillionthMonkey · · Score: 5, Informative

      WHAT, exactly does the Java security model have to do with JavaScript--an unfortunately named, but totally different, animal?!

      I'm sure you are aware of the recent marketing fiasco at Microsoft, where the company shot itself in the foot by severly diluting its new .NET trademark. Every marketer in the company wanted in on the .NET thing, and soon all product literature from Microsoft was yapping about .NET this, .NET that. Customers were confused as hell. But the .NET trademark dilution wasn't quite invented at Microsoft. Ironically, like most aspects of .NET, it had a previously existing counterpart in the world of Java.

      When JavaScript was originally invented, it was "LiveScript". There was a client version that ran in the browser, and a server version that ran on Netscape servers (and went nowhere). But it was released during the Java applet hype, and marketers at Netscape forced the name change to "JavaScript". Netscape also implemented interfaces between Java and JavaScript so that JavaScript would be more tightly coupled with the crappy JVM that was shipping in Netscape browsers back then. They were actually trying to turn JavaScript into something that would merit the horrible name they gave it.

      Specifically, you could invoke Java methods from JavaScript, and vice versa. For example, assuming you had an applet in the document using the standard <APPLET CODE="AppletClassName"></APPLET> syntax, you could (from JavaScript) call methods on the applet straightforwardly:
      var javaString = document.AppletClassName.toString();
      var javaScriptString = javaString + "";

      The javaString variable was a java.lang.String. You first had to turn it into an ordinary JavaScript string by appending "" to it. Java objects that weren't strings kept their type information in the world of JavaScript, and you could presumably call methods on them. Like, you could get a java.util.Vector, add JavaScript strings to it using addElement(), and then (back in Java) iterate through the Vector. Inside the JVM, the JavaScript strings were objects of type javascript.string or something like that. There were entire javascript.* packages containing Java mappings of JavaScript objects. An applet could acquire JavaScript references to the document, browser, etc. and manipulate JavaScript variables. (This was a long time ago during the boom, when people would actually pay you for knowing stupid stuff like this, so I may be getting the details wrong.)

      Once the browser war heated up, you simply couldn't use any of this crap since Microsoft left it only half implemented in IE. I think that invocations from JavaScript to Java worked in IE, but not the other way around (there was no way to access JavaScript from Java).

      Anyway, the article is vague, my memory of such things is old, and I never really used it more than once or twice. But if there is a hole to speak of, it looks to me like this interface I've described might have something to do with it.

    3. Re:WTF, over? by MillionthMonkey · · Score: 4, Informative

      After rereading the securityfocus link (the article itself is nonsensical), it's clear the mechanism I described only has a tangential relationship with this vulnerability.

      You start from the hacker's page X. You click on a link that goes to trusted site Y. Browser loads security policy for Y, before the page X has disappeared from the screen. During those few seconds, any clicks on links in X will execute their onClick() handlers with the privileges of trusted site Y. Where does Java come in? Well, it's hard to write an HTTP server and list directories with JavaScript! So you get an applet to do it for you- which can be done by calling an applet method from onClick(). (Or in other ways, like a popup containing the applet. In fact, onExit() would presumably be an excellent place to put this code.) The incorrect security policy (for Y) is propagated to the Java runtime from JavaScript when the method call is made.

      The bug is in JavaScript, and the timing of the browser's interaction with it. Java is merely brought in to do the dirty work once the malicious JavaScript code has fooled the browser into giving it the security permissions it needs.

      There are many, many more issues than I have discussed. The minimal release is for giving the blackhats time to play.

      I suspect the "minimal release" is because he doesn't understand what he's talking about.

  5. Oh darn... by wmspringer · · Score: 4, Funny

    Does this mean I have to download a patch for Mozilla tomorrow to fix this? ;-)

    1. Re:Oh darn... by UnknownQ · · Score: 4, Informative

      Actually if you downloaded a patch yesterday it would have worked, this has been fixed since in mozilla since 1.3.

      --
      Wherever you go, there you are!
  6. Maybe, maybe not. by Jade+E.+2 · · Score: 5, Informative

    There was a relevant message from Dan Veditz, of the Mozilla securitygroup, on the full discolsure list just this morning. I'd post the text but the lamesness filter doesn't like it. You can read it here.

  7. Re:Maybe, maybe not. - The text of the above by Anonymous Coward · · Score: 5, Informative

    meme-boi wrote:
    > Synopsis:
    > --------
    >
    > Opera, Mozilla & Netscape with javascript enabled are vulnerable
    > to remote command execution. This has been tested on Microsoft,
    > and many many Unices. Macintosh may also be vuln.

    The exploit example you give is not remote command execution but rather a
    violation of the same origin policy. Unless there are additional details you
    are withholding this same flaw was reported on Bugtraq April 15

    http://www.securityfocus.com/archive/1/318777

    and fixed in Mozilla 1.3

    http://bugzilla.mozilla.org/show_bug.cgi?id=2011 32

    > There are many, many more issues than I have discussed. The minimal
    > release is for giving the blackhats time to play.

    If instead you'd like to give the whitehats time to fix them details would
    be gratefully received by "security" at "mozilla.org"

    -Dan Veditz
    Mozilla security group member

  8. Timesaver - The most common comments you'll see by buzzcutbuddha · · Score: 5, Funny
    The advisory states that Internet Explorer isn't affected by this vulnerability. Before someone else states it, I'll get them out of the way, silly as they may be:
    • "This must have been posted by Microsoft as FUD to get people to stay away from superior products! It's all a trick! Don't listen!"
    • "What's up Taco? I thought April Fools had passed!"
    • "Javascript serves no purpose ever, and why anyone would ever use it is beyond me!"
    • "This is why we should all be using IE. I've never had a problem with IE security! Linux [l]users sux0rs!"
    Did I miss any?
  9. Re:No, Alanis... by thebatlab · · Score: 5, Informative

    Actually, it could be considered ironic. One of the definitions for ironic is: "Poignantly contrary to what was expected or intended" So, what is generally intended in a browser vulnerability is that IE *will* be affected. It wasn't and therefore is ironic.

  10. This seems bogus. by pegacat · · Score: 5, Insightful

    At first blush this seems plain wrong.

    There's not really enough evidence in the post to go on, but the example exploit is pure nuisence java script, which has nothing to do with java

    Reference is made in the text to ancient *java* bugs, but no detail is given as to how they might be related to the current, claimed bug.

    If there's more here than meets the eye I'd like to see it, but there doesn't seem to be any meat in this announcement, it seems to be just a historical retrospective and an annoying-but-not-dangerous-or-new snippet of javascript.

    Am I missing something here?

    --
    Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird.
  11. a duck by Anonymous Coward · · Score: 5, Informative

    as reported on the full disclosure list, this doesn't let blackhats execute remote commands (or local, depending on your view point). this is "merely" (bad enough I suppose) a violation of the same-origin policy in javascript.

    the same-origin policy dictates, that any code running, cannot modify anything, which is loaded from another domain. it may not even read from variables.

    more here:
    http://lists.netsys.com/pipermail/full-disc losure/ 2003-June/010200.html

  12. Re:IE not vulnerable by Ogerman · · Score: 4, Insightful

    It's pretty clear that IE's problems are slowly but surely being squashed. When you have a user base as large as IE's, it is inevitable that these problems will be found quickly and exploited and then fixed. We can take this as an indication that the larger the user base of a software product, the faster bugs will be found and eliminated.

    It's pretty clear, judging by this and some of your former posts, that you work for Microsoft or at least enjoy spreading their nonsense FUD. Your assumptive argument--that a smaller user base means that OSS has more undiscovered bugs--is entirely illogical. ..Not to mention it flies entirely in the face of the fact that IE has the most piss-poor standards support of any modern browser. (CSS in particular).

    Now take Mozilla and Opera as opposing examples. The user base for these two browsers combined is infinitesimal compared to IE. It thus stands to reason that all of the bugs and vulnerabilities of these browsers lay dormant, waiting for someone to come along and exploit them. But without a serious user base hammering away at the product all of these problems lie wide open for any hacker to come along and abuse.

    There you go again. You seem to miss the point entirely that having code open for review allows "hackers" to find security holes much faster and easier. So if a problem exists, it gets fixed much sooner than a closed source program which requires a lot more prodding and guesswork to discover the vulnerabilities. And yet IE still has historically had far more security issues than Mozilla.

    Just because you don't use Microsoft products doesn't mean that you aren't vulnerable. You are probably more vulnerable, when you take into account the lack of users and lack of accountability of the OSS project developers.

    Yet another patently untrue statement. Microsoft products have a far worse history of vulnerabilities than Open Source alternatives. Again your comment about "lack of users" is irrelevant. And your statement that OSS developers lack accountability is entirely baseless.

    The M$ dominated world is quickly coming to an end and there's absolutely nothing you can do about it. For your own sake, wake up before you become entirely obsolete.

  13. trainwreck by anotherone · · Score: 4, Interesting

    Between the awful writing in the article, the broken examples, the Java/Javascript confusion, and the contrarian IE-is-safe-but-mozilla-isn't thing; this may very well be the worst slashdot story ever.

    --
    Username taken, please choose another one.
  14. Re:RTFA, damnit! by The+Slashdolt · · Score: 5, Informative

    I read the article and nowhere is there a spec of java code. It references previous vulnerabilities that had java code. But his vulnerabilites has zero java code. It's pure javascript.
    If you look at the exploit, he is setting a function to be called after a page is loaded on another page. This function is a JAVASCRIPT function which is then run in the context of the newly loaded page.
    He is comparing a javascript function running outside of the javascript sandbox to a java type sandbox. Like I said, I RTFA, and I UTFA (understand).

    --
    mp3's are only for those with bad memories
  15. Ouch, again! by theolein · · Score: 4, Informative

    Slashdot, you're like a second home to me, but please don't post stories like this any more. It's embarrasing. Try to look at the article, read it and evaluate it for validity before posting it.

    For the record, the Java vulnerabilities the decidedly juvenile post is talking about is the bohttpd java vulnerability that existed in netscape 4.7 browsers up to 4.76 I think it was, where the exploit enabled the jvm to turn into a http server for the whole filesystem. This was around 1999 to 2000 I think.

    However, this post has nothing whatsoever to do with java. It reads far more as if some teenager has just discovered that one can do some funky stuff with javascript, such as function callbacks, crossframe clowning around and a bit of childish mischief such as opening a miniwindow with a script to track the users movements, as a lot of pornon sites do.

    Congratulations, kid, next thing you know, they'll be calling you Mitnik ;)

    1. Re:Ouch, again! by Sonicated · · Score: 5, Funny

      Slashdot, you're like a second home to me, but please don't post stories like this any more. It's embarrasing. Try to look at the article, read it and evaluate it for validity before posting it.

      Aww, that almost brings a tear to my eye. I'm going to hate to see how the dupe affects you..

      :)