cvs commit: src/sbin/nologin Makefile nologin.c

[David Schultz]

On Sun, Feb 22, 2004, Tim Kientzle wrote:
> David Schultz wrote:
> >On Sun, Feb 22, 2004, Tim Kientzle wrote:
> >>Colin Percival wrote:
> >>
> >>>Report login attempts to syslog.  Due to the statically-linked nature of
> >>>nologin(8) ...
> >>
> >>Why is nologin statically linked?
> >
> >Because of environment-poisoning attacks such as the following:
> >
> >	das at VARK:~> setenv LD_LIBRARY_PATH /home/das/exploit
> >	das at VARK:~> \login -p 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.
> 
> Hmmmm....  Several other solutions come immediately to mind:
>   * Handle this in pam (or even in login)
>     (Just check if the user's shell is /sbin/nologin and
>     reject the login if it is.)
>   * Install /sbin/nologin setuid nobody or setgid nogroup
>     That would disable LD_LIBRARY_PATH processing for it.
>   * Have login -p not pass LD_LIBRARY_PATH
> 
> Of these, the first is arguably the best, the second easiest
> to implement.  The third I'm unsure about; I can't
> really picture a scenario where login -p should pass
> LD_LIBRARY_PATH, but that's hardly conclusive.
> 
> I agree, by the way, that there should be a way to
> "mark" a program as ignoring LD_LIBRARY_PATH at
> compile-time (other than making it setuid/setgid).

Your first and third proposals would add special cases, and it's
hard to guarantee that you've covered all the cases.  LD_PRELOAD
comes to mind.  The second proposal is a hack, but it seems to be
a much better hack than the static linking one we have right now.
Please go ahead and implement it if you're so inclined, or I can
take a look at it in a few days.  It should be a two-line change.

One unfortunate side-effect of dynamically linking root (and
/bin/sh in particular) that is still unsolved is that custom
versions of nologin that people have written as shell scripts are
now insecure.  Effectively, 'sh -p' is no longer useful.  On one
of the systems I use, for instance, there's a shell script that
prints an informative message for users whose accounts were closed
due to abuse or expiration.  Thus, it would be useful to
ultimately have a more comprehensive solution.