How does Carbon Black Cloud work?
Carbon Black Cloud operates on a traditional client-server model, wherein the cloud-based infrastructure is leveraged to process and analyze data, eliminating the need for additional on-premises infrastructure. This architecture enables seamless deployment, as only the client agents need to be installed on the systems designated for monitoring.
As part of the security assessment, we conducted an in-depth examination of the interactions between various components, as well as the data collection processes employed by the agents on monitored systems. Specifically, we evaluated the VMware Carbon Black Cloud Linux Sensor (version 2.16.0.2566828) and the VMware Carbon Black Cloud Windows Sensor (version 4.0.0.1292), with a focus on their connectivity to the cloud infrastructure.
The following sections will provide an overview of three notable security issues that were identified during our assessment and subsequently reported to VMware Carbon Black Cloud.
CVE-2024-11035: Memory Leak
Further analysis revealed the presence of such paddings in response headers transmitted by the handlers within RepMgr.exe. One specific handler was identified as vulnerable to a memory disclosure issue, where it leaks partial memory addresses of the application within these paddings. This vulnerability can be triggered by sending a specially crafted message with a too large body size specified in its header. The response header sent back by the application, corresponds to the following C-structure, which includes padding bytes to ensure proper alignment:
struct ResponseHeader {
uint32_t magic; // 0xCBCBCBCB
uint16_t unk; // 0x0001
// uint8_t padding[2]; // 0x0000
uint32_t payload_size; // 0x00000014
uint8_t unk2; // 0x00
// uint8_t padding[3]; // 0x00007F
};
The last three bytes of the response header contain the prefix 0x00007F of a memory address. However, since the padding is only three bytes long, the rest of the memory address is overwritten by unk2 and payload_size. Those memory leaks seem to be a general issue with the handlers implemented by RepMgr.exe, and it is possible that other handlers leak complete addresses. Due to time constraints, we were unable to examine all handlers of the application.
If a memory address is leaked, this information can be exploited to bypass security mechanisms such as Address Space Layout Randomization (ASLR), potentially creating an opportunity for successful exploitation of other memory-related vulnerabilities.
There are several strategies to mitigate memory leaks of this nature. One straightforward approach is to utilize the memset function to clear the C-structure before filling it with data. Alternatively, the compiler can be instructed to pack structures without padding using the __attribute__((packed)) directive, thereby eliminating padding bytes. To provide additional assurance that the compiler is not introducing padding, the size of the C-structure can be verified using a static_assert statement.
The vulnerability has been addressed in version 4.0.3 of the CBC Windows Sensor, with Broadcom assigning CVE-2024-11035 and issuing a corresponding security advisory. Although we were unable to validate the patch due to time constraints on our access to the CBC infrastructure, the fix is reportedly in place to mitigate this issue.
Insufficient Detection of Agent Deactivation
A vulnerability has been identified in the detection of agent deactivation on Linux systems within the Carbon Black Cloud platform. Currently, the dashboard does not provide clear notification when an agent is deactivated, and systems with inactive agents may still appear as “online” for an extended period. This can lead to an inaccurate representation of the system’s state, potentially resulting in undetected security breaches. If an attacker is able to deactivate an agent, there is a high likelihood that this action will go unnoticed.
To enhance the detection and visibility of agent deactivation events, two key measures are recommended:
Firstly, it is suggested that the Carbon Black Cloud platform be configured to highlight events that indicate agent deactivation, including manipulations of the agent service such as stopping, disabling, killing, or masking the cbagent service, as well as similar actions on other relevant services like cbdaemon.
Secondly, to ensure accurate system state representation, it is recommended that agents be displayed as offline in the dashboard as soon as they are deactivated. This will prevent the misleading display of systems as “online” when the agent is actually inactive, thereby reducing the risk of undetected security breaches.
Broadcom acknowledges the issue but does not classify it as a security vulnerability. They consider service shutdowns as normal behavior and prioritize detecting indicators of compromise. As this is a valid argumentation and prevents alert fatigue, it neglects the fact that the system’s dashboard inaccurately displays offline agents as online, which harms the integrity of the overall system’s state.
Unsafe Bypass Whitelist Recommendations
A further interesting finding was the recommended best practices for specifying bypass rules. Carbon Black Cloud allows the specification of bypass rules, which define folders excluded from surveillance by Carbon Black Cloud. The official documentation recommends several bypass rules, as Carbon Black Cloud would otherwise prevent the use of VDIs in certain constellations. Such rules can be found, in the official documentation. The following bypass rules recommended for VDI systems were listed:
**\Program Files*\Citrix\** **\AppData\Local\Temp\Citrix\HDXRTConnector\*\*.txt **\*.vdiskcache **\System32\spoolsv.exe
These rules are considered insecure because they begin with the wildcard character string **, which serves as a placeholder for any directory on the file system. As a result, directories such as C:\Users\phishingopfer\Downloads\Program Files\Citrix would be excluded from Carbon Black Cloud’s surveillance. This could potentially allow attackers to place malware in such directories without being detected by Carbon Black Cloud. However, it is likely that additional antivirus solutions, such as Windows Defender, are present on most systems, which would also need to be evaded by the attackers.
Following our disclosure of this issue to Broadcom, the relevant documentation has been updated.
Conclusion
In conclusion, our security assessment of VMware Carbon Black Cloud revealed three minor security issues that could potentially impact the effectiveness of the solution in detecting and preventing malicious activity on Windows and Linux systems. While these issues do not pose a critical risk, they do highlight areas where improvements can be made to further enhance the security posture of the platform.
The memory leak vulnerability in the RepMgr.exe component, the insufficient detection of agent deactivation on Linux systems, and the insecure bypass whitelist recommendations all underscore the importance of ongoing security testing and evaluation to identify and address potential weaknesses.
Disclosure Timeline
Below is a brief timeline of the disclosure process. In our opinion this process went very smoothly and Broadcom was very transparent.
- November 5, 2024: Report to Broadcom.
- November 12, 2024: Response from Broadcom with details on planned fix and acknowledgement of the memory leak (CVE-2024-11035) with rating “Low”.
- March 5, 2025: Patch release and publication of a security advisory.