RCE Security Advisory
1. ADVISORY INFORMATION
Product: Intel Data Center Manager
Vendor URL: https://www.intel.com/content/www/us/en/developer/tools/data-center-manager-console/overview.html
Type: Incorrect Use of Privileged APIs [CWE-648]
Date found: 2022-07-16
Date published: 2022-12-07
CVSSv3 Score: 7.4 (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
This vulnerability was discovered and researched by Julien Ahrens from
3. VERSIONS AFFECTED
Intel Data Center Manager 5.1 (latest) and below
Energy costs are the fastest rising expense for today’s data centers. Intel® Data
Center Manager (Intel® DCM) provides real-time power and thermal consumption data,
giving you the clarity you need to lower power usage, increase rack density, and
prolong operation during outages.
(from the vendor's homepage)
5. VULNERABILITY DETAILS
The latest version (5.1) and all prior versions of Intel's DCM are vulnerable to a
local privileges escalation vulnerability using the application user "dcm" used to
run the web application and the rest interface. An attacker who gained RCE using
this dcm user (i.e., through Log4j) is then able to escalate their privileges to
root by abusing a weak Sudo configuration for the "dcm" user:
dcm ALL=(ALL) NOPASSWD:/usr/local/bin/SDPTool
dcm ALL=(ALL) NOPASSWD:/usr/bin/cp
dcm ALL=(ALL) NOPASSWD:/usr/bin/chmod
The Intel Server Debug and Provisioning Tool (SDP Tool) must be installed for the
Data Center Manager to be vulnerable. Successful exploits can allow an authenticated
attacker to execute commands as root. In this way, the attacker can compromise the
victim system's entire confidentiality, integrity, and availability, thereby allowing
to persist within the attached network.
6. PROOF OF CONCEPT
Just one way of exploitation is by replacing the current sudoers configuration:
1.Create a new sudoers configuration file using the compromised "dcm" user in i.e. /tmp/
2.sudo chmod 440 /tmp/sudoers
3.sudo cp sudoers /etc/sudoers
None. Intel thinks that this is not a vulnerability and therefore does also not assign
a CVE for it.
8. REPORT TIMELINE
2022-07-16: Discovery of the vulnerability
2022-07-16: Reported to vendor via their bug bounty program
2022-07-18: Vendor response: Sent to "appropriate reviewers"
2022-07-26: Vendor states that the vulnerability "depends on something that does not exist (eg; RCE)."
2022-07-26: Sent a clarification that a compromise of the "dcm" account is indeed necessary, but there have been RCEs in the past (i.e. through Log4j)
2022-09-22: Vendor has troubles to reproduce the bug and asks for another PoC
2022-09-22: Sent a clarification about the PoC
2022-09-22: Vendor states that the report "does not clearly demonstrate a vulnerability in DCM" and the report will be closed.
2022-09-23: Provided the vendor with a PoC utilizing Log4shell (CVE-2021-44228) in a former version of DCM
2022-10-10: Vendor asks whether the Log4shell bug is still reproducible in the latest version of DCM
2022-10-10: Made clear that Log4shell is not the point about the report
2022-10-11: Vendor states "We do not clearly see a a vulnerability demonstrated in DCM"
2022-10-12: [Back and forth about the provided PoCs]
2022-10-12: I'm giving up.
2022-12-07: Public disclosure