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.)
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
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.
meme-boi wrote:
1 32
> 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=201
> 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
-
"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?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.
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.
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.
c losure/ 2003-June/010200.html
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-dis
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
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..
WHAT, exactly does the Java security model have to do with JavaScript--an unfortunately named, but totally different, animal?!
.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.
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
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.