[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100111105208.71b62424@redhat.com>
Date: Mon, 11 Jan 2010 10:52:08 +0100
From: Tomas Hoger <thoger@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Christoph.Pleger@...tu-dortmund.de
Subject: Re: CVE id request: GNU libc: NIS shadow password
leakage
On Sat, 9 Jan 2010 00:09:09 +0100 Christoph Pleger
<Christoph.Pleger@...tu-dortmund.de> wrote:
> > I may be missing something here, or perhaps I'm not remembering
> > correctly, but NIS basically doesn't have any security in this
> > respect. This bug implies that a user has some sort of access to
> > the NIS client, but the NIS server would happily hand out the same
> > data if the malicious user asked for it (not using glibc let's
> > say). While this may be a glibc bug (I doubt it, as it would just
> > be a false sense of security), I this this is a non issue.
>
> No, that's not true. I have no experience with Linux NIS servers, but
> when the NIS server runs on Solaris (Sun Microsystems is the inventor
> of NIS), the shadow password information, which is in the
> passwd.adjunct.byname map, on the NIS clients can only be seen by
> root. When other users call for example "ypcat
> passwd.adjunct.byname", they get an error message that the map does
> not exist. Also, on Solaris NIS clients, the shadow password cannot
> be seen with getpwnam.
According to ypserv.conf man page [1], it is possible to restrict data
from some map only to clients using a privileged (< 1024) source port.
Does Solaris possibly do the same (when configured to do so)?
[1] http://linux.die.net/man/5/ypserv.conf
--
Tomas Hoger / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
