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.)
However, it seems to be related to both, hence Java/Script. Read past the title, too.
webpage
His anouncement is unfortunate in its proclamation that the problem is with Java. In reality the problem is with Javascript. While the names may be similar, java and javascript are unrelated. This is a Javascript problem, not a Java problem.
mp3's are only for those with bad memories
The second link to the page with a java applet which loads an off-site image apears to work in Camino (macos x, based on mozilla source tree). Aparently, it is vulnerable.
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.
I believe Safari is also immune to this.
Nothing from nowhere I'm no one at all
konqueror doesn't show this - whatever you call it.
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
Followup:
This page opens up a BBC java nav bar, which, according to the java security model, should not be able to. I tested this with MSIE for Mac, and the bar was not loaded. Mozilla Firebird for OSX also loads the applet (im)properly
I just tested with both Safari v74 (1.0b2) and v48 (1.0b), the example hack provided in the link did not work.
You can get the java sdk & re compiled with either GCC 2.95 or GCC 3.2 from the blackdown mirrors. You should find the closest mirror to you from the blackdown.org website. Here's the path to the GCC 3.2 version of the 1.4.1 sdk which is hosted at ftp.tux.org: /pub/java/JDK-1.4.1/i386/01/j2sdk-1.4.1-01-linux-i 586-gcc3.2.bin
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.
The exploit involves both Java and Javascript. It seems to involve having the user execute a Javascript program, which downloads a non-sandbox Java class file.
It seems the problem is not with Java, but with the browser being fooled to believe it's loading a page from a site other than the one it is actually loading the page from. The browser then passes this wrong information to the Java runtime, which then works as expected - allowing an applet to do things it would not normally be allowed to do.
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
Basically, JavaScript is used to trick the browser into loading an unsandboxed Java applet.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Netscape did have an implementation of Java, which was used in versions 3.xx and 4.xx. Right on top of the paragraph you quote, it says "circa 2000" - it's just a reminder of an older bug.
Not to say this is an actual Java vulnerability - it's just Javascript fooling the browser into thinking it's download an applet from site A when it's in fact being downloaded from an attacker's site.
Yes, I meant "expected" but misspoke. And yes it is ironic. Maybe re-read the definition of ironic again after replacing "intended" with "expected" in my comment.
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!
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...
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
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.
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.
No, it's not running out of the sandbox. The bug is in the javascript which allows the page developer to secretly access a website behind your back. This website happens to also load an applet. Java then applies the usual sandbox restrictions to that website (i.e. you can't go anywhere else, no local file access, etc.).
The applet can access the same information on your PC as normally (i.e. almost nothing). And the applet can communicate with server applications on on the website. The security risk is the same as with any other applet on any other site. The only difference is that the browser makes the choice of loading it instead of you (just like with popups). You think you're visiting server x and you are redirected to server y.
The fix for this bug is to fix the javascript implementation. Not a single line of the java implementation needs to be changed for this. Apparently this has been done in Mozilla already.
Jilles
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?
He is proving you can climb over one of the walls in the security system. It looks harmless because what he wrote is harmless in itself. The people capable of fixing the problem also know what you can do once you've climbed that wall. There is an entire history of old attacks that are all sealed off by a single security wall. If you can bypass that wall then all the old exploits work again. I think the Javascript/Java confusion is over the fact that BOTH seem to be involved. Java is safe because it runs inside the sandbox walls. The posted code shows there's a way to climb over the sandbox wall. All the old attacks work again.
He said "here's a gun" and mentioned that there's old ammunition lying around. Script kiddies generally know how to use a loaded gun, but they don't know how to dig up ammunition and load that gun. The people who know how to fix the problem just need to see the gun to understand what they need to fix.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.