KDAB Hotspot 1.3.x and 1.4.x through 1.4.1, in a non-default configuration, allows privilege escalation because of race conditions involving symlinks and elevate_perf_privileges.sh chown calls.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[day\] \[month\] \[year\] \[list\]

Date: Tue, 14 Mar 2023 12:41:21 +0100
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Security issue in Hotspot elevate\_perf\_privileges.sh (CVE-2023-28144)

Hello list,

this report is about a possible security vulnerability I found in the Hotspot
\[1\] project.

An openSUSE packager for hotspot requested a review of a Hotspot update to
version 1.4.1. This version contained a newly added D-Bus helper and Polkit
authentication. During the review I found a vulnerability in the helper script
\`elevate\_perf\_privileges.sh\` that is likely not exploitable by default, but
could easily become a local root exploit when Polkit configuration is changed
or an alternative authentication mechanism with weak authentication
requirements is used.

\[1\]: https://github.com/KDAB/hotspot.git
\[2\]: https://bugzilla.suse.com/show\_bug.cgi?id=1208808

Introduction
============

Hotspot is a GUI application for doing performance profiling anylsis
based on Linux performance counters. This report is about the v1.4.1 version
tag in the upstream repository.

The Issue
=========

Hotspot temporarily changes Linux Kernel sysctl settings and permissions of
the \`debugfs\` and \`tracefs\` file systems to allow running the GUI application
as unprivileged users. The issue is related to privilege escalation logic
which is carried out by the \`elevate\_perf\_privileges.sh\` script. This script
is invoked as root via a range of potential mechanisms like pkexec, kdesu or a
D-Bus based KDE kauth authentication helper. The mechanism is selected during
runtime with a prioritization of kauth > pkexec > kdesudo > kdesu.

The script receives the path to a temporary file which is by default safely
created in /tmp via the \`QTemporaryFile\` class in "src/perfrecord.cpp:142".
The script contains the following logic during early startup:

\`\`\`sh
    if \[ ! -z "$1" \]; then
        olduser=$(stat -c '%u' "$1")
        chown "$(whoami)" "$1"
        echo "rewriting to $1"
        # redirect output to file, to enable parsing of output even when
        # the graphical sudo helper like kdesudo isn't forwarding the text properly
        $0 2>&1 | tee -a "$1"
        chown "$olduser" "$1"
        exit
    fi
\`\`\`

The two \`chown\` invocations on the temporary file result in a temporary change
of the ownership of the temporary file to root, which is originally owned by
the unprivileged user. It changes ownership of the provided path first to
\`root\`, then reexecutes itself, then changes ownership back to the original
user.

This offers the following attack vectors:

- giving ownership of an arbitrary file to root
- giving ownership of an arbitrary file to the unprivileged user

The script accepts arbitrary paths and doesn't check where the file is located
and what its ownership is. Thus the path can also be a file in any other
directory. Therefore even without having to win a race condition or using a
symlink attack, an attacker can simply specify a path to an already existing
file owned by root e.g. /etc/shadow, which will in the end be owned by the
unprivileged user.

It can be argued that this script can only be invoked as root if the root
password has been supplied to kdesu, pkexec or the Kauth framework and thus
requires root privileges in the first place. Since the Polkit authentication
framework is likely used though, there is a certain chance that users or
integrators want to get rid of the "annoying" authentication dialog and change
the Polkit policy to something like "yes" for active users to make the
elevation work out of the box. In this case all locally logged in users could
trigger the exploit without authenticating as root.

Potential Fix
=============

I recommended to upstream to replace the currently overly complex privilege
escalation logic, that potentially uses a range of alternate privilege
escalation mechanisms, by a single clean approach like using \`pkexec\`. Towards
the helper script subprocess Pipes should be used for consuming the output
instead of passing a temporary file path to it. This way the problematic
\`chown\` calls will no longer be needed.

At the moment no proper is available and upstream will require more time to
address the issue. Using Polkit and the default upstream Polkit policy there
should not be immediate danger, but users need to be aware that relaxing the
authentication requirements in any way gives way to the local root exploit.

Upstream added a commit \[3\] that allows to "opt-in" the risky authentication
feature during build time.

\[3\]: https://github.com/KDAB/hotspot/commit/65a246ce9196462081483fd07d97678dcfe36b9c

Further Hardening
=================

The privileged operations that the script currently performs are the
following:

    sysctl -wq kernel.kptr\_restrict=0 kernel.perf\_event\_paranoid=-1
    mount -o remount,mode=755 /sys/kernel/debug
    mount -o remount,mode=755 /sys/kernel/debug/tracing

Granting world read access to the debug and tracing file systems is a
bit coarse grained. Sadly these kernel file systems don't support ACL
entries. If that would be possible then temporarily adding a dedicated ACL for
the unprivileged user would have been a viable approach.

I recommended to upstream to investigate the option to use a dedicated hotspot
group that is granted access to the file systems. Furthermore there might be a
possibility to use the capability \`CAP\_PERFMON\` in conjunction with the lower
level \`perf\` tool to obtain the necessary privileges.

Affectedness and CVE Assignment
===============================

The problematic use of \`chown\` in the helper script has been introduced in the
upstream commit 3b4682565f0e53f903f3ad0f3f2c0f236d382efb \[4\] and has been
present since release v1.3.0.

I decided to request a CVE for this issue even though it is likely not
exploitable by default, because of the simplicity of exploiting it and the
complexity of the overall privilege escalation logic in Hotspot. Mitre
assigned CVE-2023-28144 for the issue.

\[4\]: https://github.com/KDAB/hotspot/commit/3b4682565f0e53f903f3ad0f3f2c0f236d382efb

Timeline
========

2023-03-09: I contacted the main upstream author about the vulnerability,
            offering coordinated disclosure.
2023-03-10: The upstream author agreed to publishing the issue without
            embargo time, because there will be no proper fix available in
            the short term. Users should be made aware of the issue right now.

            We discussed various security aspects of the current code and
            potential remedies and improvements.
2023-03-13: I received the CVE from Mitre and started publishing the available
            information.

Best Regards

Matthias

-- 
Matthias Gerstner <matthias.gerstner@...e.de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
 
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

**Download attachment "**signature.asc**" of type "**application/pgp-signature**" (834 bytes)**

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.

CVE-2023-28144: security - Security issue in Hotspot elevate_perf_privileges.sh (CVE-2023-28144)

One researcher thinks trust is broken in AD. Microsoft disagrees that there's a security vulnerability. But enterprise IT environments should be aware of an authentication gap either way.

An access control gap in Microsoft's Active Directory (AD) service may allow users within Windows environments to access domains beyond those for which they are authenticated, all while IT admins are none the wiser.

AD, Microsoft's catchall identity management service for authenticating computers, printers, users, or really anything participating in an IT environment, is built into most Windows domain-type networks. Tens of thousands of organizations use the service, including 90% of Global Fortune 1000 companies, according to Frost & Sullivan.

Network administrators use AD to manage authentication across a domain, ensuring that intended users — _only_ intended users — can access the resources they're allotted — _only_ those they're allotted.

In a report published March 14, however, Charlie Clark, security researcher at Semperis, detailed how a user can escape the guardrails within AD, and access domains for which they were not explicitly granted permission.

"It massively increases the attack surface for an attacker," he explains, "and obviously, the larger the attack surface, the more likely it is that an attacker can find an exploitable bug."

**MSFT AD's "Transitive Trust" Problem**

According to the transitive property of mathematics, if a = b and b = c, then a = c.

In AD, if domain A connects to domain B, and domain B connects to domain C, domains A and C may or may not be able to access one another, depending on whether they share a "transitive trust." As stated in Microsoft's documentation, "transitivity determines whether a trust can be extended outside of the two domains with which it was formed."

Two domains belonging to two different organizations might bear an "external trust" — a form of trust that's set up manually in AD, which is nontransitive. However, herein lies the issue that Clark found: that external trust can be used by one company to access sister domains within the same group (what Microsoft calls a "forest") as the second, for which no official external trust has been established, Clark says.

"If what we thought about non-transitive trusts were true," Clark explains, an authenticated user from one domain would "only be able to target the specific domain they've got a trust with. They wouldn't be able to move around the forest to other domains."

Instead, "any account within the trusted domain will be able to authenticate against any domain within the entire forest in which the trusting domain resides," he wrote in his analysis.

A malicious user who figures out how to burrow around a forest at will can access resources, reach accounts, and find data they otherwise should not.

"It allows an attacker to have a much larger attack surface from any low-privileged account on a trusted domain," Clark reasons, because "if you manage to take over a single domain within a forest, it's very easy to take over the whole forest."

Clark first reported his findings to Microsoft on May 4, 2022. On Sept. 29, Microsoft wrote in an email that "we have determined that this submission does not meet the definition of a security vulnerability for servicing. This report does not appear to identify a weakness in a Microsoft product or service that would enable an attacker to compromise the integrity, availability, or confidentiality of a Microsoft offering." With that, the company closed the case.

“We provide many mechanisms for limiting resource access when using external trusts in a forest trust environment," a Microsoft spokesperson explained. "For example, by applying an authentication policy to resources at any granularity to allow or deny authentication based on any security descriptor. Customers can also set a deny-by-default posture which only allows those users to authenticate to accounts where the user has the allowed-to-authenticate right. We are continuously researching ways to improve security for future releases. More information is available in our authentication policy documentation.”

**Why Trust Matters**

Clark worked as a systems administrator for over 15 years, and a pen tester for six. "Every medium to large business or infrastructure that I've worked with has had external trusts," he claims. By that logic, most of AD's clients are likely at risk right now, he alleges, if additional protections haven't been put in place.

Microsoft's recommendations aside, to protect against this form of access control abuse, Clark recommends that admins remove all external trusts. If this is not possible, then monitoring which users are accessing what is the next best thing.

The most important thing, in the end, is awareness. Otherwise, admins may fall prey to a false sense of security. They "can see that a trusted domain is a higher risk. So they may apply greater security to that domain," Clark explains, but "they might not apply the same level of security to the rest of the domains within the forest," despite the similar risk.

"I think the main thing is to make system admins aware that this is possible," Clark concludes. By knowing this, "they can harden the rest of the domain sufficiently."

Access Control Gap in Microsoft Active Directory Widens Enterprise Attack Surface

Windows HTTP.sys Elevation of Privilege Vulnerability

CVE-2023-23410

Windows Bluetooth Driver Elevation of Privilege Vulnerability

CVE-2023-23388

Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability

CVE-2023-23404

Windows Graphics Component Elevation of Privilege Vulnerability

CVE-2023-24910

Windows Media Remote Code Execution Vulnerability

CVE-2023-23402

CVE-2023-23401

Windows DNS Server Remote Code Execution Vulnerability

CVE-2023-23400

Windows BrokerInfrastructure Service Elevation of Privilege Vulnerability

Tag

#windows