Date: Sun, 22 Feb 2004 18:56:47 -0800 From: David Schultz <das@FreeBSD.ORG> To: kientzle@acm.org Cc: Colin Percival <cperciva@FreeBSD.ORG> Subject: Re: cvs commit: src/sbin/nologin Makefile nologin.c Message-ID: <20040223025647.GA43467@VARK.homeunix.com> In-Reply-To: <403944D8.6050107@kientzle.com> References: <200402221003.i1MA3PW0024791@repoman.freebsd.org> <403944D8.6050107@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 22, 2004, Tim Kientzle wrote:
> Colin Percival wrote:
> >
> > Modified files:
> > sbin/nologin Makefile nologin.c
> > Log:
> > Report login attempts to syslog. Due to the statically-linked nature of
> > nologin(8) ...
>
> Why is nologin statically linked?
>
> Nothing else in /sbin is statically linked now.
Because of environment-poisoning attacks such as the following:
das@VARK:~> \login -p test
Password:
Last login: Sun Feb 22 16:25:26 on ttypf
<VARK>
This account is currently not available.
das@VARK:~> setenv LD_LIBRARY_PATH /home/das/exploit
das@VARK:~> \login -p test
Password:
Last login: Sun Feb 22 18:55:40 on ttypf
<VARK>
This account is currently not available.
Exploit worked. Executing a shell.
$ unset LD_LIBRARY_PATH
$ whoami
test
$
This attack was executed with a dynamically-linked /sbin/nologin
and a special libc.so.5 in the /home/das/exploit directory that
replaces the _exit() stub with a routine that spawns a shell.
Note that this attack also works with OpenSSH provided that the
locked out user has a ~/.ssh/environment file.[1]
Admittedly, making /sbin/nologin static is a kludgy solution.[2]
It would be far better if we had a link option or something that
altered the behavior of rtld in the same way as setting the setuid
bit, but at link time.
[1] I think Theo might have changed his mind about this
questionable feature and disabled it by default in
recent versions of OpenSSH. See the PermitUserEnvironment
option in sshd_config(5).
[2] One could also argue that /sbin/nologin itself is a kludgy
solution because it only mediates shell access, and that a
PAM module is a much more appropriate way to address the
problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040223025647.GA43467>