update-passwd ignores LDAP and other NSS sources

Bug #712710 reported by Danny Sauer on 2011-02-03
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
base-passwd (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: base-passwd

The update-passwd tool does not seem to respect groups defined in databases other than /etc/group. I recently upgraded a Lucid system, and got this message

----
Setting up base-passwd (3.5.22) ...

update-passwd has found some differences between your system accounts
and the current Debian defaults. It is advisable to allow update-passwd
to change your system; without those changes some packages might not work
correctly. For more documentation on the Debian account policies please
see /usr/share/doc/base-passwd/README.

The list of proposed changes is:

Adding group "cdrom" (24)
Adding group "video" (44)
Would commit 2 changes

It is highly recommended that you allow update-passwd to make these changes
(a backup file of modified files is made with the extension .org so you can
always restore the current settings).

May I update your system? [Y/n]
----

I opened another terminal, and ran a couple of perl one-liners:

----
sauer@stinky:~$ perl -le 'print scalar getgrnam(cdrom)'
24
sauer@stinky:~$ perl -le 'print scalar getgrnam(video)'
44
----

The perl commands had reasonable output given that the cdrom group is defined in LDAP, which is where I manage a whole bunch of users and groups for a group of systems:

----
sauer@stinky:~$ grep -w group /etc/nsswitch.conf
# pre_auth-client-config # group: compat
group: files ldap
sauer@stinky:~$ ldapsearch -x cn=cdrom | grep -v -e ^# -e ^$
dn: cn=cdrom,ou=Group,dc=cloudmaster,dc=com
objectClass: posixGroup
objectClass: top
cn: cdrom
gidNumber: 24
memberUid: haldaemon
memberUid: sauer
memberUid: mythtv
search: 2
result: 0 Success
----

I need to add LDAP users to some of these groups, and I don't want to do so by editing individual group files on all the boxes. This is why I *have* LDAP. :) As such, it would be nice if the update-passwd program would use the libc calls to see if groups are defined, rather than just blindly working on the files.

This is also a marginal security issue, as it's possible that someone could have a different name-id mapping in their repository v/s the passwd or group file for a system account. Since most remote-database (AD, LDAP, NIS, etc.) allow local files to override the remote repository, but Linux NSS merges the two repositories (depending on the program), it's possible that someone could end up being granted access that they're not supposed to have when a local group is manipulated. As these are the lower-level system groups, it seems worthwhile to be as safe as possible when handling them. :)

Danny Sauer (ubuntu-dannysauer) wrote :

Hopefully someone can correct my spelling of "ignores". :) And probably change LDAP to NSS... Sigh.

Kees Cook (kees) on 2011-02-05
security vulnerability: yes → no
visibility: private → public
Danny Sauer (ubuntu-dannysauer) wrote :

Scenario:

Group "printers" is defined in LDAP with GID=4 because that's how it was always defined in some legacy corporate Unix environment. All users who are allowed to print are a member of this group. A local administrator notices this and configures his system to have the "adm" group - which Ubuntu wants to be GID=4 - to have a GID of 1004.

The nsswitch.conf file is configured to use files then LDAP for group lookups (which most any tool or how-to will do) , and the sudoers file which comes with Ubuntu grants unlimited access to people in the adm group, Time passes, and everything works. The admin decides that this Ubuntu thing is alright, that the Q/A system doesn't suck, and updates seem to work well. He decides to enable automatic instalation of updates.

Oh no! There's a security-related update to base-passwd! Well, rest easy admin - the automatic update setting will pull the update down and install it. The update-passwd tool, running in "assume yes" mode, helpfully notices that some foolish admin has changed the adm GID to something other than 4, so it changes it back. It sends an email, but the admins don't notice that email amid all the other notifications that they only spot-check.

Now, when users log in, they still get membership in the printers group from LDAP. The system still records this in the group vector as "4", because that's the number returned by a getgrnam("printers") call. So, file access and whatnot based on the printers group still works just like it always has. No one notices that running "id" or "groups" shows them as a member of adm - because no one runs those commands in normal day to-day usage. They don't do an "ls -l" on the print queues, either, and most programs don't do a double reverse-lookup from name to gid and back to name just to ensure that things are kosher. But eventually, a malicious user does notice that he's a member of the adm group - because this is what a getgrgid(4) returns. Maybe he ran "groups". Who knows. Oh, and he runs "sudo -l". Since sudo uses the name of the group, it doesn't notice that the GID has changed; it doesn't care that there's a conflict. "My, look at the sudo rule I've gained..."

Now everyone who used to only be able to print because they were in the printers group (or whatever the LDAP GID=4 groul granted, you get the point) has unlimited sudo access. One "sudo -i" later, and the logs have been tampered with, removing a way of tracking down the malicious user. All because update-passwd didn't bother to respect the NSS settings, and modified the local group file in an unsafe way.

This is not a particularly contrived situation; as part of a team which manages several thousand Unix systems from multiple vendors (and which is finally in the process of moving to a centralized user repository), I see local-remote UID/GID mismatches pretty regularly. It usually doesn't result in this kind of privilege escalation, but then, maybe we just missed it. :)

As such,I maintain that this bug at least enables a security problem, if not causing one outright.

Colin Watson (cjwatson) on 2014-01-14
summary: - update-passwd igonres ldap
+ update-passwd ignores LDAP and other NSS sources
Changed in base-passwd (Ubuntu):
status: New → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers