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]. Collin [1] https://github.com/shadow-maint/shadow/blob/710c4d4f88fa32dfc4c4d1f714e935d8bff6ae00/src/grpconv.c#L181-L200
