Carbon Black Cloud sensor version 3.4.1.7 is a generally available release for macOS only.
This release builds on work completed for the macOS sensor versions 3.3.3 and 3.3.4. For more information about the cumulative changes in this sensor version, please see the macOS 3.3.3 and 3.3.4 release notes.
In these release notes:
Important notification about the certificate whitelist process
Devices that are upgrading to 3.4 from sensor versions 3.0 and older should have the new code signing certificate (Team ID 7AGZNQ2S2T) whitelisted prior to the sensor upgrade. This procedure is required because of a Team ID change in the Carbon Black Cloud code signing certificate that was introduced in the 3.1 sensor release.
VMware Carbon Black recommends using an MDM-compatible mass deploy solution to push the updates, pre-approve, and whitelist the KEXT code signing certificate.
See the following User Exchange article about granting the sensor Full Disk Access as required by macOS 10.14+: macOS 10.14+ Privacy Changes and Granting the macOS Sensor Access.
Release checksums
|
3.4.1.7 DMG SHA256 Checksum
|
9b505b56a9d909db5e2d27609ad6ed8a9eda620af1867ed4485b004da27391ea
|
|
3.4.1.7 PKG SHA256 Checksum
|
251a09e0bf2ce53b5899abd72126f6a6d1075e0f7d82c14bc5197e3b86cf187d
|
Enhanced investigations with CB ThreatHunter
CB ThreatHunter brings incident response capabilities to macOS on the Carbon Black Cloud, delivering endpoint visibility and enhanced search to our cloud platform. To enable a macOS endpoint to return CB ThreatHunter data, your organization must have purchased CB ThreatHunter and must have the macOS 3.4 sensor installed on the endpoint. The macOS 3.4 sensor supports CB ThreatHunter standalone, as well as any combination of CB Defense, CB LiveOps, and CB ThreatHunter. To read more about CB ThreatHunter, see https://community.carbonblack.com/t5/Cb-ThreatHunter/ct-p/CbThreatHunter
VMware Workspace ONE on macOS
The Carbon Black Cloud console now reports the universally unique identifier (UUID) of macOS endpoints and shares that information with VMware Workspace ONE. This enables Workspace ONE macOS users, who are also Carbon Black users, to access the Carbon Black Cloud.
Fixed in this release
Efficacy enhancements and bug fixes (since 3.3.4)
|
Issue ID
|
Description
|
|
DSEN-4105
|
CB Defense: Enhanced Reputation feedback loop with the cloud that results in more timely updates, thereby effectively improving prevention of near-0 day malware.
|
|
DSEN-5854
|
CB Defense: Increased length of reported process command-line strings. This is in addition to command-line reporting improvements that were introduced in the macOS 3.3.3 sensor release.
|
|
DSEN-6549
|
CB Defense: Rule case sensitivity. Blocking and Isolation and Permission "by path" rules are now evaluated as case-insensitive on Mac. Please review your "by path" policy rules, as their scope may now be broader.
|
Known issues and caveats
|
Description
|
| There is an infrequent known issue where Malware Removal inaccurately reports the actions that were or were not taken. |
|
Issue ID
|
Affected Product
|
Description
|
|
DSEN-2735
|
Carbon Black Cloud
|
Device name in sensor management is case sensitive.
|
|
DSEN-2700
|
Carbon Black Cloud sensor
|
Rare issue where repmgr service sporadically crashes on shutdown, typically when the cloud is unreachable. The issue has no impact on end-user or product efficacy.
|
|
DSEN-2543
|
Carbon Black Cloud sensor
|
The unattended install script does not accept multiple long options. The workaround is to always provide a value (such as 0 or 1) next to every long option following = character; for example: --downgrade=1 --skip-kext-approval-check=1.
|
|
DSEN-3740
|
Carbon Black Cloud
|
When a device is removed from an AD domain, the sensor is still reflected within that domain in the Endpoints page and remains in a sensor group. The sensor must be taken out of auto-assignment to make policy updates to that sensor. As a workaround, you can manually remove the sensor from the AD group and assign a policy (click into the device, turn off auto-assign, and change the policy).
|
|
DSEN-3752
|
Carbon Black Cloud
|
Cloud uninstall of the sensor takes a long time due to a delay in the uninstall request. Local uninstall is not delayed.
|
|
DSEN-3669
|
CB Defense
|
Old canary files, specifically with variable or random file names, are not always properly cleaned up by the sensor. This can cause ransomware false positives.
|
|
DSEN-5744
DSER-17746
|
CB ThreatHunter
|
There is a known issue where code signing certificates are not present in event details or process data views.
|
|
DSEN-6036
|
CB ThreatHunter
|
The ability to block blacklisted hashes is not available in CB ThreatHunter-only orgs. The implementation of hash banning in a future sensor release will bring this functionality to macOS. Customers with both CB Defense and CB ThreatHunter will have full hash banning capabilities.
|
|
DSEN-6570
|
Carbon Black Cloud
|
Carbon Black PSC and older Confer branding is still present in some files and directories specific to the sensor installation. While the sensor installer name might imply CB Defense only, it supports both CB Defense and CB ThreatHunter, and actual sensor functionality is determined by the customer’s organization. Branding and product names will be updated in a future release.
|
