[Security Advisories / CVE] [LinkedIn Profile]

CVE-2024-52869 - Teradata SLES 15 Linux user privilege escalation via incorrect group assignment following a SLES 12 > 15 move


Vendor and Affected Products
Vendor: Teradata Corporation, https://www.teradata.com
Product: Teradata SUSE Linux Enterprise Server (SLES)
Versions affected: SLES 15 Service Pack (SP) 2

Risk / Severity Rating
CVSS 3.1 Base Score: 6.0 (medium risk)
CVSS 3.1 Vector: AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L

Vulnerability Description and Impact
Linux user accounts on Teradata servers upgraded from Teradata SUSE Linux Enterprise Server (SLES) 12 to 15 may be assigned to incorrect Linux groups via primary and/or supplementary group assignment, which can lead to user accounts having more (or less) privileges than they'd normally have depending on the group they are assigned to. In select cases, the privileges granted to the user account have been shown to allow indirect root access.

SUSE is responsible for the assignment of group identifiers (GID) to default system / service Linux user accounts. At SUSE's discretion, they may change the default primary and/or supplementary GIDs set for a particular Linux user account in one OS version to different GIDs in a newer OS version. In the case of Teradata system moves / migrations from Teradata SLES 12 to 15, Teradata's teradata-osmigration package scripts, which are used to migrate Linux users and groups from one OS version to another, migrates the users and groups without taking into account any GID changes enacted by SUSE in the new OS version. This can lead to Linux users being assigned to incorrect GIDs per the user accounts intended purpose.

Impact will vary depending on the purpose of the user account assigned to an incorrect group, the incorrect group(s) the user is assigned to, the process(es) running under the user account, and the resource(s) the process(es) have access to. This vulnerability carries high to critical risk when a user account is incorrectly assigned to a high privileged Linux group (e.g., the "disk" group), where it may be combined with other vulnerability exploits (e.g., remote code execution) to gain higher system privileges.

Caveats / Prerequisites
Exploiting this vulnerability requires either direct (e.g., interactive terminal) or indirect (e.g., command injection) execution of code as the Linux user account assigned to an incorrect group.

Proof of Concept
The following proof of concept code shows the "systemuser" user account, which is a mask for the actual user account observed, incorrectly assigned to the "disk" group and being leveraged to read /etc/shadow data, which contains encrypted passwords that are normally only readable by the "root" user and "shadow" group members. An /etc/ohno directory is also created, showing the directories user and group owners as "root". This shows debugfs is effectively operating as the "root" user through "disk" group membership. "systemuser" was incorrectly assigned to the "disk" group as part of a Teradata SLES 12 to 15 move / migration. An attacker could use direct or indirect access to "systemuser" to read any file, regardless of the file's owner or permissions, on any partition readable by debugfs, since the "disk" group has read/write access to all files in Teradata SLES 15 by default.

systemuser@node:/> id uid=491(systemuser) gid=491(disk) groups=491(disk)
systemuser@node:/> /usr/sbin/debugfs -w /dev/sda2
debugfs 1.43.8 (1-Jan-2018)
debugfs: mkdir /etc/ohno
debugfs: cat /etc/shadow
...
root:$6$xRbRWCnq$dt0********************************************:18930::::::
...
user1:$6$rounds=100000$6BM.******************************************:19269:7:90:10:90::
...
debugfs: quit
systemuser@node:/> exit
logout
node:~ # ls -ld /etc/ohno
drwxr-xr-x 2 root root 4096 Jun 26 06:18 /etc/ohno
Solution
Default system / service user accounts on Teradata SLES 15 servers moved / migrated from Teradata SLES 12 by Teradata support personnel after 8/28/24 *should* be assigned to their correct respective groups per Teradata's response to this vulnerability. Non-default user accounts (e.g., user accounts created by customer system administrators) *may* still be assigned to incorrect groups depending on the group identifier (GID) in Teradata SLES 12. Teradata recommends system administrators manually validate all Linux user group assignments following a Teradata SLES 12 to 15 move / migration.

Teradata is working on releasing a script to identify and correct select user accounts set with incorrect GIDs in Teradata SLES 15 SP2 and above. Teradata has not provided an estimated release date for the script as of the date this vulnerability was published.

Timeline
2024-06-17 - Initial discovery
2024-06-26 - Vulnerability reported to vendor via vendor support portal
2024-06-28 - Vendor acknowledgement
2025-01-03 - Vulnerability publication