Common Vulnerabilities and Exposures assigned an identifier CVE-2010-0015 to the following vulnerability:
nis/nss_nis/nis-pwd.c in the GNU C Library (aka glibc or libc6) 2.7
and Embedded GLIBC (EGLIBC) 2.10.2 adds information from the
passwd.adjunct.byname map to entries in the passwd map, which allows
remote attackers to obtain the encrypted passwords of NIS accounts by
calling the getpwnam function.
The upstream fix for this can be found here:
I had another look at this issue. The problem that was reported was specific to the way passwd.adjunct.byname NIS map data was handled. passwd.adjunct is password shadowing mechanism used by some SunOS / Solaris versions. glibc NIS client, when seeing passwd map data of certain format (password field staring with "##"), tries to query NIS server for passwd.adjunct data too and make password hash part of passwd map data if available. NIS server may refuse to provide that data to clients not connecting from privileged port if configured to do so (default ypserv.conf configuration in RHEL prevents access to passwd.adjunct and shadow maps by default, even though none of those maps are created by default).
The issue raised by the original reporter is the use of nscd may make passwd.adjunct data available to non-privileged users too. This may happen when nscd is running as root, however, on RHEL, nscd is run under dedicated user account nscd. Hence, unless nscd configuration is changed to use root user, it can not send queries from privileged port and will not get replies non-privileged user can not get via other means.
This does not affect shadow map data, which is not cached by nscd.
Given the limited benefit this fix adds on top of weak NIS security, there's no plan to backport this fix to Red Hat Enterprise Linux 4 and 5. The glibc packages in Red Hat Enterprise Linux 6 already contain upstream patch, which allows configuring NSS, using ADJUNCT_AS_SHADOW directive, to use passwd.adjunct data to synthesize shadow map data rather than adding passwords to passwd map.
The Red Hat Security Response Team has rated this issue as having low security impact. We do not currently plan to address this flaw on Red Hat Enterprise Linux 4 and 5. This issue does not affect Red Hat Enterprise Linux 6.