Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.