[2215] in bugtraq
Re: Linux NIS security problem hole and fix
daemon@ATHENA.MIT.EDU (Joerg Czeranski)
Fri Sep 8 00:54:12 1995
Date: Fri, 8 Sep 1995 00:57:04 +0200
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Joerg Czeranski <joerg.czeranski@informatik.tu-clausthal.de>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
Ken Weaverling <weave@hopi.dtcc.edu> wrote:
> [...]
>
> OK, here it goes... Ya know how you put +, -, and @ entries in /etc/passwd
> to incorporate stuff from an NIS map? Well, you can login with that
> entry too. + is a damn easy login to try, since most /etc/passwd files
> using NIS use an entry like...
>
> +:::::
>
> ... as the last line.
>
> This is why just disabling NIS is not enough. If you forget to remove these
> entries from /etc/passwd, you are screwed.
>
> The fix is to put a * in the password field of the NIS entries. This prevents
> login from the local /etc/passwd but doesn't lock the incorporated NIS
> entries (a bit inconsistent, but oh well) example:
>
> +:*::::
But beware: on other implementations of NIS (notably SunOS, Solaris,
Ultrix and Dec Unix (OSF/1)) this entry has a different meaning:
it indeed means to include the NIS passwd map and replace the password field
with "*", i.e. lock all the passwords.
On those implementations the only correct entry is "+::::::" (or
"+::0:0:::", as the UID and login-GID field can't be overridden).
It is also often valid to drop the trailing colons and simply
use "+".
Anyway it seems to be rather non-trivial to add NIS to a libc, as
the correct behaviour seems to be documented only by "the way SunOS does
it is right".
> CERT advised me of the above fix. They couldn't test the fix since they
> don't have a LINUX machine anywhere. Pretty incredible that no one at
> CERT runs a free Unix that can run on a 386 with 4 megs...
Not that much incredible if you take into account that Linux is a kernel,
not an OS, and that a very high percentage of security-relevant bugs
are discovered in libraries, tools and configuration files.
CERT would have to run at least all of the major distributions,
and each in a variety of configurations (with NIS added and without),
to be in a position to really support Linux.
It wouldn't hurt if they ran the current Slackware (or whatever is the
most often used distribution) in some standard configuration though.
joerch
--
Joerg Czeranski EMail czeranski@informatik.tu-clausthal.de
Osteroeder Strasse 55 czeranski@rz.tu-clausthal.de
D 38678 Clausthal-Zellerfeld WWW http://www.in.tu-clausthal.de/~injc/
