[646] in linux-security and linux-alert archive
Re: [linux-security] sliplogin hole explanation
daemon@ATHENA.MIT.EDU (Yury Shevchuk)
Sun Mar 31 15:57:10 1996
Date: Sun, 31 Mar 96 22:55 +0400
To: Olaf Kirch <okir@monad.swb.de>
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <m0u2pHl-000HRgC@monad.swb.de>;
from Olaf Kirch at Sat, 30 Mar 1996 02:16:57 +0100
From: sizif@botik.ru (Yury Shevchuk)
In message <m0u2pHl-000HRgC@monad.swb.de> Olaf Kirch writes:
>We all know that you can pass most environment variables to a login
>shell when started through telnetd. Assuming you have the password for a
>sliplogin account on a Linux box, you can pass the ENV variable in this
>fashion.
>
>The attack goes something like this:
>
>ENV='`/evil/command`' telnet
>telnet> environ export ENV
>telnet> open targethost
>
>You then log into your regular slip account, which executes sliplogin as
>your login shell. Sliplogin, in turn, runs the /etc/slip.login shell
>script using bash. At startup, bash evaluates *and expands* ENV to
>obtain the name of a startup file to use instead of .bashrc, and
>faithfully executes /evil/command.
This is more than only a sliplogin hole! The same attack is
applicable to every account with shell script as a login shell. Of
course, you won't right away get the root shell, as in sliplogin's
case, just a shell with the account's uid, but...
Perhaps other people are wiser, but I had a couple of accounts with
login shell set to /bin/false... which is a shell script! I tried
your exploit, works great. :-(
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.
Sounds like interpreted login shells should be banned? Would be a
pity. Another extremal solution is to zap most of environment in
telnetd, which again is a loss of functionality. What about a simple
wrapper which cleans environment before executing the interpreter?
Shells scripts intended for use as login shells would start like
#!/bin/zapenv /bin/sh
....
and zapenv could be as simple as
main()
{
char *env[] {
"PATH=/usr/bin:/bin:/usr/sbin:/sbin",
NULL
};
if (argc < 2)
exit (1);
++argv;
execve (argv[0], argv, env);
return 1;
}
Thanks a lot for your alert.
-- Yury Shevchuk
<sizif@botik.ru>
