[2219] in bugtraq
Linux NIS security problem hole and fix
daemon@ATHENA.MIT.EDU (Ken Weaverling)
Sat Sep 9 02:49:53 1995
Date: Thu, 7 Sep 1995 13:15:58 -0400
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Ken Weaverling <weave@hopi.dtcc.edu>
X-To: bugtraq@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
Amazing.
I was told by someone that this hole is "well known" and has been discussed
on the LINUX security list for a while now. A few people have emailed me
telling me what it was too, so it is obvious that this is "known" about.
I am now even more a believer of full disclosure. We purchased a commercial
version of LINUX just a little while ago, and the hole exists. How am
I supposed to protect stuff if I don't even know about it? Sigh....
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:
+:*::::
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...
Sorry this is posted so close to the weekend (thurs at 17:15 UT). Hopefully
it will clear the bugtraq mailer and get out to everywhere by Friday, even
though it is already Friday at some parts of the planet. :-(
I was going to wait until Monday, but if it is already known, it should
be known by all.
