Re: Possible Netscape / Mozilla bug

[Kevin Buhr <buhr@telus.net>]

Gordon Paynter <gordon.paynter@ucr.edu> writes:
> 
> Obviously, this is bad.  Suppose user2 maliciously sets their display
> to some other machine, and runs netscape.  Netscape has user1's
> Mozilla launch a new window on the remote machine, and user2 has
> access to user1's stored passwords etc.

If "user2" has authorization on a display, then "user2" can control
*all* applications on that display, even if they're owned by a
different user.  "user2" can read the contents of windows, simulate
keystrokes and mouse events, and do whatever else "user2" feels like.
It's part of the way X is designed.  Yes, it lets processes owned by
different users (even on different machines) connect to the same
display, but no, it makes no attempt to protect those processes from
each other.

In particular, the scenario you suggest should fail at the point
"user2" runs the "netscape" script with the DISPLAY set to a different
target.  Unless that target display is misconfigured (or has been
intentionally configured to trust "user2"), "user2" doesn't have
authorization to connect to it, and nothing happens (except that
"user2" gets some error messages).

Of course, even if it worked---if "user2" did have authorization on
the target display---Mozilla would open a new window *on the target
display*, so it's not as if "user2" would suddenly have a window on
her own display to start fiddling with.  She'd have to be cleverer
than that, but---as I said---if "user2" has authorization to connect
to "user1"'s display, then "user1" is practically at "user2"'s mercy
anyway.


That being said, there *is* a bug in Netscape 4.77's "netscape-remote"
command (which the "netscape" script uses to connect to an existing
"netscape" or "mozilla" window).  It doesn't bother checking that the
user running the command matches the owner of the "mozilla" window; it
just looks for the first "mozilla" window it can find that's running
on the same display.  "mozilla"'s implementation fixes this.  If you
do a:

        mozilla -remote 'openURL(foo)'

then "mozilla" will use the current value of the LOGNAME environment
variable to see whose "mozilla" window should be remotely controlled.
Unfortunately, "mozilla"'s implementation is broken in a different way
and won't reliably find "mozilla" windows under all window managers.
There's a patch:

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

but it hasn't been applied to the trunk yet.


On the flip side, note that it wouldn't be easy for the target
"mozilla" process to refuse to be controlled by a process owned by a
different user.  The control is done via X events, and these don't
carry any sort of user identifier with them.  The target "mozilla"
process receives an event and acts on it---it's not trivial for it to
figure out what user sent that event, and it's probably not worth the
bother.

-- 
Kevin Buhr <buhr@telus.net>


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org