[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11134

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #8 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11134

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11134

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
This is not a security issue because the data is still available through tools
like ypcat, even if glibc's NSS module filters it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[drepper at redhat dot com]

------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-04-07 07:56 -------
Subject: Re:  getpwnam shows shadow passwords of NIS users

Hello,

> The server can regulate which process can read the passwd.adjunct
> database using the source port number.  A value < 1024 would indicate
> privileges.  If an attacker can illegally bind a socket to a low port
> security is already compromised.

Normal permissions should prevent an attacker from illegally binding a
socket to a port < 1024. Of course there can be a security hole that
gives root privileges. But a security hole of that kind gives access to
everything, in spite of that no sensible administrator gives
permissions 777 to all files. So, we must find a solution for the
normal case which says that no ordinary user can use a port < 1024,
not a solution for a case where another security hole is already
present.

Of course a user can connect his own notebook to the network, be root
on it, which allows to use a port < 1024, and read the encrypted
passwords. But that problem can be solved by other means, for example
by IPSec authentication.

> That's how it is meant to be used.  In this model processes with
> privileges can get to the information.  Especially because I don't
> think imitating the shadow file using the passwd.adjunct content is
> going to work.

Where do you see a problem? I've been using this for some time now and
the only problem I found was the overwriting of the password field,
which I solved by the modified patch.

> You say there are two fields missing in passwd.adjunct.  In theory
> perhaps true but I have not found anywhere any indication that
> usually the file contains any information except the first two
> fields.

Right, that is why I put empty strings into these fields. These
field are defined in libc6, what will getspnam do if they are not
present?

> There is no way in Sun's implementation to enable behavior
> like this?  There is no setting in Sun's ypserv to restrict access
> based on ports?  I cannot change it without a good reason.

The access IS restricted on ports. But that does not help when,
on the Linux client side, nscd is in use.

> The current libc implementation works perfectly if you use the model I
> described.  You get a full passwd file for privileged users and a
> version without the password for non-privileged users.

Unfortunately, that is not true. The current implementation allows
EVERY user to use the getpwnam library call to see the encrypted
password of any NIS user.

> This is a
> sensible model and your patch would cause it to stop working.

No, my patch MAKES it working.

Regards
  Christoph

------- Additional Comments From drepper at redhat dot com  2010-04-07 14:41 -------
I decided to implement this but only as a non-default mode.  It can be selected
by a new variable in /etc/default/nss.  This is as far as I'm willing to go.  As
I explained, the current code has its own justification and is not broken.

Your last patch still contained a bunch of mistakes.  The change I checked in
really has not much to do with it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-04-06 22:53 -------
I'm not so sure about either change.

The server can regulate which process can read the passwd.adjunct database using
the source port number.  A value < 1024 would indicate privileges.  If an
attacker can illegally bind a socket to a low port security is already
compromised.  The code in libc will ignore the error from being denied access
and will use the original entry from /etc/passwd as-is.

That's how it is meant to be used.  In this model processes with privileges can
get to the information.  Especially because I don't think imitating the shadow
file using the passwd.adjunct content is going to work.

You say there are two fields missing in passwd.adjunct.  In theory perhaps true
but I have not found anywhere any indication that usually the file contains any
information except the first two fields.  That's not really the correct content
for the file.  It means no password aging etc happens.


Changing the implementation along your patch sounds arbitrary.  The current
behavior re filling in the password might be used by some people.  There is no
way in Sun's implementation to enable behavior like this?  There is no setting
in Sun's ypserv to restrict access based on ports?  I cannot change it without a
good reason.

The bigger problem is the synthetic shadow file.  I don't like this at all.  If
you want a shadow file, why don't you export one from the server?  I realize
that if you say you don't want a shadow file and restricted access to passwd and
the server doesn't have port-based access control that you then want these
changes.  But these are lots of ifs.

The current libc implementation works perfectly if you use the model I
described.  You get a full passwd file for privileged users and a version
without the password for non-privileged users.  This is a sensible model and
your patch would cause it to stop working.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[drepper at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #4491 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[drepper at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #4498 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[Christoph dot Pleger at cs dot tu-dortmund dot de]

------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-02-17 13:18 -------
Created an attachment (id=4605)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4605&action=view)
Another try


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[Christoph dot Pleger at cs dot tu-dortmund dot de]

------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-02-17 13:15 -------
Hello,

I am sorry that my patch for the NIS shadow password security
vulnerability introduced a new bug. One of my NIS users informed me
that she could not login any more after she had used chsh to change her
login shell. The reason was that in the shadow file, the encrypted
password had been replaced by an 'x'. This happens because in my
patch, file nis-pwd.c, the string "##<username>" is replaced with "x". 

I thought that this replacement is necessary to let libc6 search for
the encrypted password in the shadow map. But now I found out that it
is not necessary and that without it everything works fine: logging in,
changing password and changing the shell.


I have attached a new patch that simply lets the password field of the
passwd.byname map alone.

Regards
  Christoph

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[Christoph dot Pleger at cs dot tu-dortmund dot de]

------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-01-06 07:58 -------
Created an attachment (id=4498)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4498&action=view)
New patch

I was told that there are missing parantheses in  free result. Obviously, I
sent an obsolete version of the patch. Here is the version that I used to
compile glibc successfully.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11134] getpwnam shows shadow passwords of NIS users

[Christoph dot Pleger at cs dot tu-dortmund dot de]

------- Additional Comments From Christoph dot Pleger at cs dot tu-dortmund dot de  2010-01-05 09:28 -------
Created an attachment (id=4491)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4491&action=view)
Patch for NIS shadow problems

Here is my patch in form of an attachment.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11134

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.