SUMMARY: "*" in password field of NIS magic token

Date: Tue Dec 06 1994 - 22:43:06 CST

The original question was:
> Why does putting an asterisk ("*") in the password field of
> the NIS magic token ("+:*:0:0:::") disable the passwd map?
> Let me clarify. I have an NIS client with a very bare /etc/passwd file.
> The last line of the file is "+::0:0:::", telling the system to append the
> global NIS passwd map. This works fine.
> Then one day I read that the above line is a big security risk. Should NIS
> stop running for some reason, the line would act as a UID 0 login for the
> user "+" with no password! Therefore, a "*" should be placed in the
> password field, making the line read "+:*:0:0:::". But when I tried it,
> the NIS passwd map was not appended. Take the "*" out again, no problem.
> The same holds for adding a single user NIS entry (i.e., "+user::0:0:::"
> works, "+user:*:0:0:::" doesn't). Ironically, /etc/group does NOT suffer
> from the same problem.
> This has been true for ALL releases of SunOS from 4.0.3 to 4.1.3_U1 Rev. B.
> Does anyone know what the problem is? And is the risk of NIS failing a
> formidable threat?

And the answer is:

1. First of all, the "*" in the password field does not disable the passwd
    map. It merely replaces that [password] field for all lines in the map.

    In other words, all NIS-included users would not be able to login because
    their password field contains "*". But the passwd map is still available,
    as evidenced by the UID->username translation still working when you do
    'ls -lg'.

    The confusion arose because the O'Reilly & Associates book I was using
    ("Managing NFS and NIS", (C) Copyright 1991) said only the last three
    fields (gecos, home dir., shell) could be overridden in by a "+" entry
    in the local /etc/passwd. The truth is that the password field can also
    be overridden!

    The moral of this story is to leave the password field blank for "+"
    entries unless you REALLY wan't to override it.

2. Secondly, there is no security risk whatsoever by having a "+" entry in
    a client's /etc/passwd with a blank password field, at least on NIS-
    aware systems such as SunOS.

    What this means is that system calls in SunOS (such as getpwent, used
    to return a passwd entry) know about NIS, regardless of whether NIS
    processes are running on the system or not. The special "+" entries
    will NOT be interpreted as real users. (Thanks!)

    However, if you are truly paranoid, you can replace the 0 in the UID and
    GID with 65534 (nobody's UID/GID). I tested this and it works also. But
    this is completely unnecessary since the line will not be interpreted as
    a real user anyway. Furthermore, the 0 UID/GID will not override real
    users' UIDs/GIDs in the NIS map - NIS always supplies both the UID and
    GID. The 0's in the "+" entry are just dummy values - place holders.

Special thanks to the following:
    Tom Orban <>
    Ted Nolan <>
    Tom Crummey <>
    Casper Dik <>
    C.R. Ritson <>
    Paulo Licio de Geus <>

Here are the original responses:
>From: Tom Orban <>

I read about that in some security book a while back and tried it on
a machine running 413 I believe. With NIS not running, I still couldn't
log in with user name of "+". Try it and let me know if you find something

Bottom Line: I think sun did some workaround to prevent that.

>From: Ted Nolan SRI Ft Gordon <>


I don't have a specific answer to your question, but I just killed ypbind
on my machine then tried to login as '+' (SunOs 4.1.3). It didn't let
me. Are you sure leaving it blank is a security hole? Have you tried it?

                                Ted Nolan
>From: Mr T Crummey (DIJ) <>

Hello Matthew,

The * in the line means replace the passwords in all YP inlcuded fields
with *. This means that people cannot log in as you have found out.
The security hole you refer to is imaginary as the getpwent call will not
interpret this line as a real user even if YP is not running as it is the
same library call no matter what.

>From: Casper Dik <>

Only on systems not aware of NIS this might be a problem. Using a "*"
is a problem on any NIS aware version of SunOS I've ever used.
Not using a "*" is not a security problem on SunOS (any release).
It is on some otehr vendors systems (probably Ultrix :-)

>From: "C.R. Ritson" <>

You can override password entries too. Adding the * forces all
passwords to be interpreted as *, I guess, although I have previously
only seen this behaviour for single-user entries, I suspect this
must be happening to the global include token.

This is only a potentail security risk if your machine fails to
bind to a server, or comes un-bound. I don't know how rare that
is. What I ended up doing was to change the UID/GID on the template
line to something innocuous - eg the ones already in use for nobody,
or else 65535.

Chris Ritson.
>From: (Paulo Licio de Geus)

As far as I know, any field that is filled in an NIS entry (a "+"
line) takes precedence over the corresponding field in the NIS map.
In fact, I've told the system that all accounts not matched previously
(the line starting with "+:") should have a single password, whose
encryption results int he string "*", which I believe is not possible
via crypt(1). So, all you NIS accounts have in fact blocked from any
login. Nothing strange about that...

Matthew R. Hofener, System/Network Administrator (
NIST Great Lakes Manufacturing Technology Center (GLMTC)
A Division of Cleveland Advanced Manufacturing Program (CAMP)

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:16 CDT