VMware Carbon Black EDR 7.2.0 | 17 AUG 2023 | Build 7.2.0.90725 Check for additions and updates to these release notes. |
VMware Carbon Black EDR 7.2.0 | 17 AUG 2023 | Build 7.2.0.90725 Check for additions and updates to these release notes. |
VMware Carbon Black EDR Linux Sensor 7.2.0 is a Minor release that introduces SHA-256 hash reporting and various bug fixes and other small enhancements.
SHA-256 Hash Reporting
Beginning in 7.2.0-lnx, the Linux Sensor generates and reports the SHA-256 hash for executed binaries.
VMware Carbon Black EDR sensors operate with multiple operating systems. For the current list of supported operating systems, see the Linux Sensor OER.
This document provides information for users who are upgrading to VMware Carbon Black EDR Linux Sensor 7.2.0 from previous versions and users who are new to VMware Carbon Black EDR. This document supplements other VMware Carbon Black EDR documentation at https://docs.vmware.com/en/VMware-Carbon-Black-EDR/index.html.
Warning: EDR Linux Sensors versions 7.x do not support EL6 distros (RHEL/CentOS 6.x). Attempting to upgrade EL6 endpoints will result in a failed upgrade and the sensor will be offline.
To install the new sensor:
Set your yum repo appropriately: modify /etc/yum.repos.d/CarbonBlack.repo with the appropriate baseurl, if needed.
Baseurl= https://yum.distro.carbonblack.io/enterprise/stable/$releasever/$basearch/
Clear the yum cache.
yum clean all
Download the installer.
Substitute the cb-linux-sensor-installer name for cb-linux-sensor-installer-7.2.0.90725-1.noarch.
The <package local download directory> is a directory such as /tmp.
Run the following command to download the installer:
yum install --downloadonly --downloaddir=<package local download directory> <package>
Change your directory to the <package local download directory> from Step 3.
Run the following command to install the package:
rpm -i --force <package>
(current package to use: cb-linux-sensor-installer-7.2.0.90725-1.noarch)
Run the following command to make the new installation package available in the server console:
/usr/share/cb/cbcheck sensor-builds --update
Note: Within the Upgrade Policy section of Sensor Group settings, if the Automatically upgrade to the latest version setting is enabled for Linux sensors, the Linux sensors in that group will automatically upgrade to this new version.
The new sensor versions should now be available via the console. If the following warning occurs:
warning: /tmp/cb-linux-sensor-installer-7.2.0.90725-1.noarch: Header V4 RSA/SHA1 Signature, key ID 6ac57704: NOKEY
Refer to this Knowledge Base Article: How to provide public key for Linux sensor package.
For any other issues, see Contacting Support.
EA-22427: Process tracking and reporting
This release includes various improvements to process tracking and reporting, which resolve the following Engineering Assist (EA) tickets:
EA-22427, EA-22426, EA-22219, EA-21805, EA-21306, EA-21203, EA-19190, EA-18557, EA-17569, EA-16731, EA-16182, EA-15860, EA-15254, EA-14378, EA-14192, EA-13715, EA-13174, EA-13145, EA-13391, EA-12994, EA-11522, EA-10720
These improvements can be summarized in two main categories:
Inaccurate process reporting when an exec() → exec() sequence occurs
In previous versions, when ‘Process A’ with Process ID (PID) ‘N’ initiates ‘Process B’ using exec(), and ‘Process B’ initiates ‘Process C’ using exec(), without a preceding fork() event, ‘Process B’ overrides the address space of ‘Process A’ and therefore gets assigned the same PID, ‘N’, and ‘Process C’ overrides the address space of ‘Process B’ and gets assigned the same PID, ‘N’, too. Due to the overriding of PID, the information of the middle process, ‘Process B’, and its associated events would be lost. Beginning in 7.2.0-lnx, exec() sequences are correctly tracked by the sensor and the information and events associated with those processes are correctly reported to EDR Server.
Re-use of Process ID (PID) across distinct process instances
In previous versions, Process ID (PID) value is the sole identifier of an instance of a process. However, this proved to be problematic at times because the system can run out of available PIDs and therefore recycle PIDs. This means distinct process instances could have the same PID, which could lead to convolution of distinct processes and hence inaccurate process reporting. Beginning in 7.2.0-lnx, PID and the start time of the process are used to delineate unique processes, which resolves the duplication of PIDs across multiple concurrent process instances and the process reporting inaccuracies that issue created.
N/A: eBPF-based OS with a kernel version > 4.4
In previous versions running on an eBPF-based OS with a kernel version > 4.4, banning a hash failed to kill an already running process that is backed by a binary with that hash; it would only prevent new executions of that binary.
EA-9593: High CPU due to hash calculation for large files
EA-15248: Data reporting differences between CentOS 7 and CentOS 8
EA-17150: Invalid/corrupt events in cbdaemon could result in core dumps
EA-18185: Linux Sensor had a hard-coded Live Response transfer chunk size
In previous versions, the Linux Sensor has a hard-coded Live Response transfer chunk size, which would prevent the user from specifying a custom chunk size via Carbon Black EDR Server, and caused Live Response commands to fail.
EA-21373: Numerous zombie processes created by 7.1.x-lnx sensors
EA-21733: Sensor log file filled with “Dns name not found” error messages”
EA-20574: Clock delta between sensor and server resolved
In previous versions, the Linux Sensor did not report SenorTimeAsGMT, which prevents the Carbon Black EDR Server from calculating the clock delta between sensor and server.
EA-21891: Panic in ec_mem_cache_get() could result in endpoint crash
EA-22419: SELinux-approved label was missing from /dev/cbsensor
EA-22651, EA-21047: High CPU utilization
EA-22956: Oracle RMAN backups failed with sensor enabled
EA-23119: Application failover did not work due to cbdaemon service
EA-23225: High memory utilization
Includes EA-22850, EA-22753, EA-22657, EA-22651, EA-22621, EA-22483, and EA-22476
CB-23866: Events from sensor can have an unknown parent
CB-18239, CB-29810: PID Re-use
PID reuse on the system could cause new processes to not be suppressed when they should be.
CB-30175: Custom TLS Certificate
Proxy setting in sensorsettings.ini will not work with a custom TLS certificate.
CB-18158: Oracle UEK
Oracle UEK is not supported. The RHCK kernel must be installed prior to installing cbsensor on Oracle Linux.
CB-17033: Installation Directory
This version of the Linux Sensor Installer does not respect the specification of a non-default installation directory in cb.conf on the server – the default directory is always used.
CB-6623: ICMP Traffic
ICMP traffic is still allowed when a sensor is isolated.
CB-37627: Downgrades from 7.2.0-lnx to 6.x.x-lnx
Downgrades from 7.x.x-lnx to 6.x.x-lnx will require manual deinstallation of 7.x.x-lnx and installation of 6.x.x-lnx due to extensive architectural changes introduced in 7.0.0-lnx.
CB-37628: Downgrades from 7.1.0-lnx w/Kernel > 4.x
Downgrades from 7.1.x-lnx on systems running with a kernel version greater than 4.x to any previous sensor version will require manual cleanup of sensor packages.
CB-38504: Network Isolation does not work on eBPF sensors
VMware Carbon Black EDR server and sensor update releases are covered under the Carbon Black Customer Maintenance Agreement. Technical Support can assist with any issues that might develop. Our Professional Services organization is also available to help ensure a smooth and efficient upgrade or installation.
Use one of the following channels to request support or ask support questions:
Web:User Exchange
Email: [email protected]
Phone: 877.248.9098
Reporting Problems
When contacting Carbon Black Technical Support, provide the following required information:
Contact: Your name, company name, telephone number, and email address
Product version: Product name (VMware Carbon Black EDR server and sensor versions)
Hardware configuration: Hardware configuration of the VMware Carbon Black EDR server (processor, memory, and RAM)
Document version: For documentation issues, specify the version and/or date of the manual or document you are using
Problem: Action causing the problem, the error message returned, and event log output (as appropriate)
Problem Severity: Critical, serious, minor, or enhancement request
Note: Before performing an upgrade, Carbon Black recommends you review related content on the User Exchange and the release documentation location, the Carbon Black EDR section of docs.vmware.com.