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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
https://bugs.launchpad.net/bugs/712710
Title:
update-passwd igonres ldap
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
