Hi Collin, On 2026-05-23T20:20:38-0700, Collin Funk wrote: > Hi Alex, > > Alejandro Colomar <[email protected]> writes: > > > [This mail is in a public mailing list] > > > > Hi Serge, Danila, > > > > On 2026-05-23T09:48:48-0500, Serge E. Hallyn wrote: > >> Here's the other one that didn't make it to you. I think it was somewhat > >> low priority and I let it drop off my radar. > >> > >> ----- Forwarded message from Danila Khomichenok > >> <[email protected]> ----- > >> > >> Date: Fri, 8 May 2026 18:04:13 +0300 > >> From: Danila Khomichenok <[email protected]> > >> To: [email protected], [email protected], [email protected] > >> Subject: Re: LPE in shadow-utils > >> > >> Here is the bug report to Ubuntu: > >> https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2146812 > >> > >> On Fri, May 8, 2026 at 5:39 PM Danila Khomichenok < > >> [email protected]> wrote: > >> > >> > Hello. > >> > I previously reported a bug in Ubuntu where a user, after being > >> > removed from a group in /etc/group, could still reuse group > >> > privileges if the entry was present in gshadow. > >> > Standard commands like id and groups no longer show the user as > >> > a member, creating a hidden persistence mechanism. > >> > > >> > An attacker with existing low-privileged access could exploit this > >> > to regain membership in high-impact groups (such as docker, lxd, > >> > disk, or sudo), leading to local privilege escalation (LPE). > > > > Danila, I think this isn't too dangerous, so we should make the report > > public. Would you mind opening a public bug report on our github? > > > >> > The expected behavior is that removal from /etc/group should be > >> > sufficient to revoke group access entirely. The current > >> > inconsistency between the two files can mislead administrators and > >> > create a false sense of security. > > > > Hmmm, there's a problem. group(5) and gshadow(5) both specify a members > > list, and if they disagree, we have a problem: which source should be > > trusted? One of them? The union? The intersection? Fail if the files > > don't match? I don't have a good answer. > > > > Do you people have any opinions? > > > >> > Also, the related commands 'groups' and 'id' do not display > >> > information about the user's membership in a group, for example > >> > 'docker', as seen in the screenshot. > > > > Since there are various implementations of id(1) and groups(1), > > including GNU coreutils, I think a bug report should include maintainers > > of those projects. I've CCd coreutils@ in this email. > > I don't think the issue is too concerning. If I understand correctly, > the privilege escalation only occurs when a privileged user (e.g. root) > adds a user to a group and then later tries to remove them, but forgets > to update /etc/gshadow. Is that correct? > > In the case of GNU coreutils, we never open any of these files > (excluding the possibility of Gnulib working around some bug, but I do > not remember any cases where we have to do that). We just use POSIX APIs > for the most part. Those APIs could theoretically be implemented using > something other than /etc/groups, /etc/passwd, etc. > > Maybe is is reasonable for /etc/gshadow entries to be ignored if they do > not exist in /etc/groups. I haven't thought fully about the potential > negative impacts that can be caused by that, and would trust your > judgment much more than mine. There is a section which looks like it can > be copied from 'grpconv' to do it, though [1].
I think I agree. We may want to diagnose them (if it's easy). But yes, they should be treated as invalid and ignored. Thanks! Have a lovely night! Alex > > Collin > > [1] > https://github.com/shadow-maint/shadow/blob/710c4d4f88fa32dfc4c4d1f714e935d8bff6ae00/src/grpconv.c#L181-L200 -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
