VMware Carbon Black App Control Windows Agent 8.7.4 Release Notes

VMware Carbon Black App Control 8.7.4 | 16 MAY 2022 | Build 8.7.4.661.329

Check for additions and updates to these release notes.

What's New

This document provides change information and installation instructions for VMware Carbon Black App Control v8.7.4 Windows Agents.

Added Support for read-only VMware App Volumes (AppStacks)

An AppStack is a read-only volume containing any number of Windows applications, files, folders, registry settings, and more. An administrator assigns applications to an AppStack that they want to run in their environment for specific people or groups. In order to improve the user's experience, App Control can now detect if an application resides within an AppStack and automatically approve that file to run. Additionally, interesting files within the AppStack are not scanned when the new volume appears thus improving performance. For more information on configuring your agents for AppStacks please the section: Configuring App Control to Work with App Volumes.

Installation Instructions

As of the 8.1.4 server release, the Windows Agent no longer comes bundled with the VMware Carbon Black App Control Server, nor does it require manual (command line) steps to add it to the server.

You can upgrade Carbon Black App Control Windows Agents without having to upgrade the Carbon Black App Control Server. Please see the latest Carbon Black App Control User Guide for more information.

NOTE: This Windows Agent is compatible with App Control Server version 8.1.4 and subsequent releases

For information regarding which Windows operating systems are supported in this release, please review the Carbon Black EDR sensors & Carbon Black App Control agents document on the Carbon Black User Exchange.

Resolved Issues

The following issues were resolved in this release.

EP-13506: Fixed an issue that prevented files from being deleted on Windows XP and Server 2003 systems
EP-14051: Fixed an issue with file path based custom rules. The file path was not being normalized correctly for mounted folders. As a result some rules could not be correctly enforced (EA-19354, EA-20499)
EP-14277: Fixed an issue that under certain circumstances, an installed application would cause the agent to generate a dump file
EP-14346: Fixed an issue that caused a large number of unnecessary internal events stating “Potential deadlock: Expirations[___] SoftDeadlocks[___] BlockedTime[_____ms]”
EP-14542: Fixed an issue in which “ProcessTracking::RemoveAnalysisThreadReference: Removing analysis thread TID[____]” was appearing in kernel log messages at an inappropriate log level
EP-14641: Fixed an issue with handling yara tags (EA-20668)
EP-14965: Fixed an issue that caused a race condition and could cause the parity service to crash in some situations during user login (EA-20010)
EP-14938: Fixed an issue where the agent can potentially corrupt memory and crash when collecting metadata from an MSI file
EP-14998: Fixed an issue which caused values of kernel configuration properties to be missing in the output of “dascli configprops” command (EA-19955)
EP-15013: Fixed an issue that could potentially cause BSODs and performance issues based upon thread priority (EA-19485, EA-20757)
EP-15084: Fixed an issue "Execution Control" custom rules did not work correctly for specific types of applications ( like Windows App Store Apps ) (EA-20371, EA-19768)
EP-15145: Fixed an issue in which some MSI installations took significant amount of time to install (EA-20668)
EP-15162: Fixed an issue which caused a kernel communication thread to exit abnormally (EA-20243)
EP-15207: Fixed an issue in which 0-byte configuration files that come from the server caused problems on agent (EA-20852, EA-20670)
EP-15211: Fixed an issue caused by changes to Windows driver signing requirements that prevented the agent from being installed on Windows Server 2008 (EA-20433)
EP-15214: Fixed an issue that can cause policy problems when a policy contains more than 100 trusted users (EA-20758)
EP-15312: Fixed an issues where a service crash can occur when querying system information

Known Issues

EP-1201: On Windows 2003 x64, you may see a health check reporting improper classifications immediately after installation

This should go away after roughly fifteen minutes.
EP-1682: Carbon Black App Control does not support in-container enforcement

Users can use the Microsoft Edge Virtualization feature, but Carbon Black App Control will not enforce rules within the container. It will, however, enforce rules on anything that breaks out of the sandbox.
EP-2393: The appearance in the console of block and report events related to the Ransomware rapid config may be delayed by a minute or more
EP-5483: The agent currently tracks all the extracted content from the Windows 10 WIM image in the temp directory

A rule to ignore these writes is not yet functioning properly.
EP-5498: In some cases, the agent will report an empty installer for a given file

The file will still be correctly approved or not, as expected on the endpoint. Only reporting of the source installer is failing, not enforcement of relevant rules.
EP-6982: Carbon Black App Control does not support NTFS reparse points as exclusion paths and they should not be used with kernelFileOpExclusions configuration rules

Reparse points include such objects like symbolic links, directory junction points and volume mount points.
EP-6104: Cleanmgr.exe is a windows utility process that runs occasionally and will copy files to the "temp" folder in order to run analysis on them

These files are only copies of other files already on the machine and cleanmgr.exe never executes them.
EP-6106: An installation of a new Carbon Black App Control Agent on the latest version of Windows 10 can result in a health check error due to a miscalculation of how many events the agent should send to the Carbon Black App Control server

This problem disappears after a reboot.
EP-6107: After upgrading agents on Windows XP systems, it is possible to see signature error events stating that the installer download failed

The upgrade should be successful and there should not be any impact on the upgrade process.
EP-6197: Occasionally the agent will complain about metadata not being properly populated and trigger an Error

The Error implies a mismatch in expectation but is not expected to break functionality of the agent and can be ignored.

EP-10542: When uninstalling the agent, a Carbon Black App Control Agent dialog displays informing the user that certain applications must be closed before continuing the installation

This informational message is caused by a known msiexec defect:

https://support.microsoft.com/en-ph/help/2745579/same-file-or-service-name-causes-incorrect-fileinuse-dialog

Important: This could occur during a removal of the agent using "add/remove programs" or during an upgrade of the agent if you are using 3rd party software or a manual upgrade using msiexec. Customers that perform agent upgrades from within the Carbon Black App Control Admin console are not affected. When uninstalling the agent or performing a manual upgrade, or upgrade using 3rd party software, you can suppress this dialog with the additional msiexec command line argument "/qb-". This will disable modal dialog during manual uninstalls and upgrades.

Important: This could occur during a removal of the agent using "add/remove programs" or during an upgrade of the agent if you are using 3rd party software or a manual upgrade using msiexec.

Customers that perform agent upgrades from within the Carbon Black App Control Admin console are not affected.

When uninstalling the agent or performing a manual upgrade, or upgrade using 3rd party software, you can suppress this dialog with the additional msiexec command line argument "/qb-". This will disable modal dialog during manual uninstalls and upgrades.

The example below shows how to manually uninstall the Carbon Black App Control agent with the /qb- argument:

msiexec /x {9F2D4E59-0528-4B22-B664-A6B0B8B482EE} /qb-

This issue is not new to the Windows agent and possibly affected customers on earlier releases. A long term fix will be implemented in a future release.

Configuring App Control to Work with App Volumes

As mentioned in the What’s New section above, App Control now supports AppStacks within VMware App Volumes. To enable and control the behavior of App Control in relation to AppStacks, you must create an agent configuration property.

The property enables the agent to automatically detect AppStacks. When enabled, the agent allows all interesting files within the AppStack volume to execute. This means that all App Control rules are ignored on the AppStack volume. The assumption is that the AppStack is a gold image of applications that the organization wants to allow to run in the environment and should therefore be allowed to execute.

To apply automatic detection configuration to all of your endpoints:

Log in to your App Control Web Console.
Navigate to the URL https:// SERVERNAME/agent_config.php
Add a new configuration with the following settings:
1. Property Name: appstack_autoapprove
2. Host ID: 0
3. Value: appstack_autoapprove=1
4. Status: Enabled
Save.

When App Control sees a new volume, it automatically scans the volume for files, hashes those files, and then sends data about the files to the server. This has a performance impact on the machine, and happens each time the AppStack is loaded. Because of the nature of AppStack volumes and App Control’s scanning of newly detected files, App Control defaults to not scanning the AppStack volume. This is the recommended configuration. If you prefer to have files scanned on every instantiation of the AppStack, you must create a configuration property using the following settings:

IMPORTANT: This is NOT recommended.

Navigate to the URL https:// SERVERNAME/agent_config.php
Add a new configuration with the following settings:
1. Property Name: appvolume_enablescan
2. Host ID: 0
3. Value: appvolume_enablescan=1
4. Status: Enabled
Save.

Rapid Config

In order to prevent attackers from making standard drives appear to be App Volumes and therefore, circumventing the default deny capabilities of App Control, we recommend that you enable the VMware App Volumes Protection Rapid Config. This Rapid Config prevents users from creating junction points under c:\SnapVolumesTemp\MountPoints\.

Writable Volumes and App Volume Configuration

When App Volumes applications are present on the desktop, all writes that are happening on the desktop to any files and the registry are redirected to a writable volume. In the absence of a writable volume, an implicit writable volume (a scratch space) is created on C:\{00000000-0000-0000-0000-000000000000}\SVROOT that will keep all the changes. This may have a negative effect on the path-based approvals. Modified files will not be approved after virtualization is started because the actual file path will be different from the approved path.

App Control does not support Writable Volumes. It is important to prevent the App Control agent database from becoming corrupted. To do this you will need to exclude App Control from being copied to a Writable Volume. In the App Volumes snapvol.cfg file (found in \Program Files (x86)\CloudVolumes\Agent\Config\Default\) please add the following:

# Parity
exclude_path=\ProgramData\Bit9
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\services\ParityDriver

Upgrade Issue with Windows XP and Server 2003

Windows XP and Server 2003 lack the necessary certificates (both root and intermediate) to validate the timestamps in the signature we use. In order to upgrade these operating systems to 8.7.4 of the App Control agent customers will need to choose to do one of the following:

Option 1: Import the Missing Certificates Into the Computer Certificate Store

You can download the necessary certificates from https://community.carbonblack.com/t5/Documentation-Downloads/App-Control-Windows-Agent-Digicert-Timestamp/ta-p/112610.

Install the certificates on your machines either directly using MMC with the Certificates snap-in or use GPO. The root certificate should be imported to the Trusted Root Certification Authorities store. The intermediate certificate should go to the Intermediate Certification Authorities store. These should be imported at the machine level as opposed to the user level.

Option 2: Explicitly Trust the Timestamping Publisher

Another option is to trust the timestamping certificate. This can be a bit challenging because it requires querying the database for the correct id. Full instructions can be found on this document: https://community.carbonblack.com/t5/App-Control-Discussions/Ineligible-for-Approval-CERT-TRUST-IS-PARTIAL-CHAIN/m-p/68553/thread-id/6292

Option 3: Use the ignore_partial_chain_on_countersignatures config prop

Agents can be configured to ignore the missing countersignatures. This allows approval by publisher for files that have valid code signing chains, while ignoring errors on the counter signing chain.

Details on how to configure this can be found here:

https://community.carbonblack.com/t5/Knowledge-Base/App-Control-How-can-I-ignore-partial-cert-chain-errors/ta-p/73892

Please note that if the root certificate is not trusted (using Option 1 or 2), this method will still result in the following error: CERT_TRUST_IS_UNTRUSTED_ROOT.