Linux NIS security problem hole and fix

[weave () hopi dtcc edu (Ken Weaverling)]

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.