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
