Bug#1082326: Supplemental Group Inheritance Grants Unintended Access to GID 0

[Brian Ristuccia]

Package: proftpd-core
Version: 1.3.8+dfsg-4+deb12u3
Severity: grave

We've run into a problem with proftpd + mod_sftp + mod_sql, where a
user with no supplemental groups will incorrectly inherit supplemental
groups from the parent process. In ProFTPD Version 1.3.5, this
behavior resulted in users gaining supplemental membership in nogroup,
which had minimal security implications. In 1.3.8, it appears that the
parent process retains supplemental GID 0, which is inherited by child
processes and not overwritten if the authenticated user has no
supplemental groups.

On proftpd startup, the toplevel process supplemental groups were
previously set to those system groups associated with the user
specified in the User directive along with the group specified in the
Group directive. With the default config and system group membership,
this arrangement historically resulted in nogroup being the only
supplemental group. Since membership in nogroup provides essentially
no additional privilege, previous versions masked what appears to be a
longstanding (but questionable) behavior in proftpd where if a user
has no supplemental groups, the supplemental group memberships
inherited from the parent process are not discarded.

Unfortunately, the fix for
https://github.com/proftpd/proftpd/issues/808 removes code which
previously caused proftpd to overwrite its supplemental group
membership when configured to run as non-root. As a result, the
parent's supplemental group memberships at startup time (notably
supplemental GID 0) are retained and will be inherited by child
processes even if the User and Group directives are present. Users
with no supplemental groups of their own will keep this inherited
supplemental GID, granting them access to files/directories owned by
the root group.

-- 
Brian Ristuccia