Nasty SunOS initgroups() bug

[darrell () teleport com (Darrell Fuhriman)]

Glad to see bugtraq is functional again, despite the fair bit of
noise, it was the best source of information about.

Anyway....

When using NIS, SunOS picks the wrong field within initgroups() when there
is an empty passwd.

For instance, we had the following entry in our NIS passwd file
(this is what caused us to discover the bug.)

gopher::81:99:Public Access Gopher:/home/gopher:/usr/local/bin/rgopher

We are using shadowed passwords, but we don't have them for this entry, as
we don't want people to get a password prompt at all.

Now, what is happening is that the system (specifically initgroups()) is
using 99 as the UID by which to set groups, not 81.  This is *very* bad.

Let me show you using account blahblah (same entry as above w/ different
username and shell only)

group 99 = internal
uid 99 = jamesd
----

[90](root)claudia:~darrell# groups blahblah
blahblah: internal

[91](root)claudia:~darrell# groups jamesd
jamesd: internal russ support billing teleport majordom www wheel users progs
bbs admin ftp

[92](root)claudia:~darrell# telnet julie
Trying 192.108.254.19 ...
Connected to julie.teleport.com.
Escape character is '^]'.


SunOS UNIX (julie)

login: blahblah
> id
uid=81(gopher) gid=99(internal),groups=99(internal),0(wheel),
61(admin),81(ftp),83(majordom),86(support),
87(billing),97(www),98(russ),100(teleport),101(users),106(progs)

----
As I said, this is very, very bad.

I've been able to verify that the bug is due to using strtok(3)
to parse the passwd line, rather than sscanf(3) or something similar.

The bug only exhibits itself if NIS is running.  We've not tested
it on Solaris 2.x, BTW.

I've contacted Sun, but have gotten typically little response, so
I'm posting this here.

BTW, does anyone have a good way to detect when someone is
attempting DNS spoofing attacks?

Darrell Fuhriman
Teleport System Administration