[648] in linux-security and linux-alert archive
Re: [linux-security] sliplogin hole explanation
daemon@ATHENA.MIT.EDU (Mark Whitis)
Mon Apr 1 10:10:36 1996
Date: Sun, 31 Mar 1996 21:42:59 -0500 (EST)
From: Mark Whitis <whitis@dbd.com>
To: Yury Shevchuk <sizif@botik.ru>
cc: Olaf Kirch <okir@monad.swb.de>, linux-security@tarsier.cv.nrao.edu
In-Reply-To: <m0u3SHw-000RocC@hole.botik.ru>
On Sun, 31 Mar 1996, Yury Shevchuk wrote:
> Of course, this particular hole is easy to fix: reimplement :)
> /bin/false in C, and you are safe. But in general, the
> environment-passing feature of telnet seems to me a real Pandora box.
> The recent LD_LIBRARY_PATH hole, now the ENV hole, ... are you using
> perl for custom login shells? what about PERLLIB then? I'm afraid any
> interpreter around has at least one environment variable that can be
> exploited this way or that.
Yes, I agree. The environment passing feature of telnet has given me
the heebeegeebees ever since I first heard about it. I think telnetd
should be patch to only allow a particular list of environment variables
to be passed. The default should be to deny a variable unless it
is specifically allowed. For allowed variables, you might also
want to specify, in some cases, a list of specific allowed values
or a list of allowed characters. By default, the only two I would
allow are TERM and DISPLAY and maybe TZ and even those I have my doubts
about in some circumstances.
The rest of this message, basically deals with my doubts concerning
TERM and DISPLAY. Both of those are abusable to some degree in
the proper context.
Under System V terminfo, if you could manipulate TERM such that you
could provide your own terminal capabilities (I am looking at the
manpage under Solaris right now), there could be some unfortunate
security problems:
init_file when used with a suid root program that used termcap
to provide limited functionality, might be exploitable to display
files (/etc/password,/etc/shadow,/etc/hosts.allow,/etc/hosts.deny)
init_prog is much scarrier.
Setting TERM may be okay as long as you don't let them get at the
environment variable TERMINFO and don't have an stupid entries
in the database.
It might be possible to manipulate DISPLAY on any program which
can optionally run as an X client to bypass firewalls or send
signals from a protected port (if the program runs as suid root).
Under solaris, I was just able to connect to a server program
on port 7000 by
export DISPLAY=localhost:1000
/usr/openwin/demo/ico
This opens a tcp connection to the service on port 7000 put does
not seem to send any data (I guess it is waiting for information
from the server).
At the very least, I could use almost any X windows program this
way to probe for ports with services on the other side of a firewall
this way (since most X windows programs will report to stdout/stderr
if they cannot connect). It could also be used for denial of service attacks.
(Fortunately, in this particular case, syslogd uses udp; otherwise,
it might be possible to tie up all possible tcp connections to syslogd
using this trick. And it is conceivable that some programs could be tricked
into sending ascii strings, surrounded by newlines, in amongst all the X
requests.
On Solaris at least, I don't seem to be able to connect to ports
below 6000 by using values like "localhost:-1000" or "localhost:60536"
to try to get to port 5000.
Fortunately, there aren't too many programs which can optionally use
X windows that one might want to set up for an anonymous account.
There might be some news/mail programs out there (for example, if someone
made an X enhanced version of PINE which would run as either a termcap
or X program). Emacs or mosaic would be asking for trouble no matter how
you sliced it.
In any event, it would probably be wise to encapsulate any programs,
whether or not they use X windows or termcap, which are used for
anonymous accounts inside a C program,
not a shell script, which zorches the environment and uses exec(),
not system() to call the actual program.
--
Mark Whitis <whitis@dbd.com>; 804-962-4268
428-B Moseley Drive; Charlottesville, VA 22903
