trousers: Local privilege escalation from tss to root

Vulnerability

The trousers package in SUSE Linux Enterprise Server 15 SP1 (versions prior to 0.3.14-6.3.1) and openSUSE Factory (prior to 0.3.14-7.1) contains a symbolic link following vulnerability in its %posttrans RPM scriptlet [1]. During package installation or update, the scriptlet attempts to restore backup files from .rpmsave files located in /var/lib/tpm/. It performs a mv operation on files named system.data.auth.rpmsave and system.data.noauth.rpmsave without checking whether the target is a symbolic link [1]. This allows a local attacker with the tss user privileges to manipulate the file path.

Exploitation

An attacker with tss user access can create a symbolic link in /var/lib/tpm/ pointing to a sensitive root-owned file (e.g., /etc/shadow). For example, they run ln -s /etc/shadow system.data.auth.rpmsave [1]. When an administrator reinstalls the trousers package (e.g., zypper in -f trousers) or triggers a version update, the %posttrans scriptlet runs as root. It moves the .rpmsave file to the original filename system.data.auth, thus following the symlink and overwriting the target file [1]. The attacker must have write access to /var/lib/tpm/ and the ability to trigger a package installation or upgrade that runs the vulnerable scriptlet.

Impact

After successful exploitation, the target file (e.g., /etc/shadow) becomes owned by the tss user and group instead of root [1]. This allows the tss user to read and modify the shadow password file, subsequently enabling privilege escalation to root by altering passwords or other sensitive data. The attack leads to full system compromise from the initial tss user context.

Mitigation

The vulnerability is fixed in trousers version 0.3.14-6.3.1 for SUSE Linux Enterprise Server 15 SP1 and 0.3.14-7.1 for openSUSE Factory [1]. Users should update to these or later versions. If an immediate update is not possible, a workaround is to remove the vulnerable %posttrans section from the RPM spec file, though this may cause data loss for TPM ownership information stored in the backup files [1]. The advisory recommends using safe symlink checks and temporarily changing ownership of /var/lib/tpm to root during the restore operation [1].