VMware Carbon Black App Control Windows Agent 8.9.4 Release Notes

VMware Carbon Black App Control 8.9.4 | February 27, 2024 | Build 8.9.4.1642.836 Check for additions and updates to these release notes.

Caution:

Starting with the 8.9.4 App Control server, valid signing certificates are required for all files contained in Windows App Control agent installation packages. In February 2023, the signing certificate used to validate SHA-1 MSI's in the 8.9.4 server expired, which prevents any future Windows App Control agent installation packages from being properly validated and installed with this server version.

We recommend both customers who do and do not use Windows XP/2003 on 8.9.4 server upgrade to 8.9.6 server to ensure there are no issues with future release installations. The 8.9.6 Server contains an updated SHA-1 signing signature required to validate future installation packages of the Windows App Control agent.

Customers who do not wish to upgrade to 8.9.6 server must manually apply the new SHA-1 signing certificate to prevent these issues from occuring. You can download this new signing certificate here.

What's New

The 8.9.4 Windows Agent Release Notes provide information for users upgrading from previous versions and for users new to VMware Carbon Black App Control. This is a maintenance release.

Support for TLS 1.3

In conjunction with App Control Server 8.10.2 or higher, the Windows Agent 8.9.4 nows supports the TLS 1.3 communications protocol on Windows 10 and 11 systems by default.

New agent configuration property

App Control uses Microsoft's wuapi.dll in order to enumerate and store information about what updates have been applied to the system for diagnostic purposes. This methodology works correctly in some versions of Windows but in others it can cause problems like preventing access by other processes to the Windowsupdate.log file.

In App Control Windows agent 8.9.4, we have added a new agent configuration property called "collect_windows_updates." In versions of Windows prior to Windows 10, this property will be set to 0 by default. This means the agent will not collect Windows Update information. In Windows 10 or higher, the value of this configuration property will default to 1. This change is related to customer issue EA-23315.

Resolved Issues

• EP-16878: Agent now correctly handles renamed files in a Trusted Directory

  In situations where a Trusted Directory is located in a DFS namespace, files copied to DFS based Trusted Directory were not crawled and approved. (EA-21988)

• EP-19614: Fixed issue in which manual upgrades of the agent failed

  In version 8.9.0 we made some changes to help identify paths on DFS servers which caused the improper normalization of the path name which led to this issue.

• EP-19647: Fixed a rare case where App Control's cb7zip.dll file did not update to the correct version during an upgrade

• EP-19707: Fixed an issue where the agent would attempt to get publisher info from an unsigned file, which would raise an Event

• EP-20098: Fixed an issue where agent version 8.9.2 introduced a hang inside a tracing call when creating a process

  In 8.9.2, we added additional kernel logging to make it easier to solve rarely reproducible issues. However, that additional logging caused a deadlock on systems that generate large numbers of processes. (EA-24180)

• EP-20101: Fixed an issue where some Windows files were not approved by the Windows update process

  In Windows 11 22H2, the process wuaucltcore.exe is being used by Windows as part of the Windows update process. We have added that process to our list of approved processes used by Windows Updater.

• EP-20242: Fixed an issue with Performance Optimization (PO) rules to allow remote endpoints to rename a file on a server without the server agent analyzing the file (EA-24099)

• EP-20276: Fixed an issue which caused approval rules to not work in certain circumstances

  In 8.9.0, we introduced a bug where files that were previously approved would no longer execute because the file had been renamed. (EA-24038)

• EP-20279: Fixed an issue where machines could not perform file uploads with TLS 1.3 protocol set

  This occurs in machines that do not support TLS 1.3 but that have this secure protocol option set in Windows HTTP Services.

• EP-20304: Fixed an issue in which rules based on DFS paths would not work for newly logged in users

• EP-20348: The service initialization code has been modified to avoid database locking issues during the initialization process

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-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-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-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.

  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 {EnterGUIDHere} /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.

• EP-13016: SDHC Cards are not supported.

• EP-14223: When using 8.6.x servers, policy and enforcement levels may not display correctly for 8.6.x Windows agents installed on Windows 11.

  The 8.7.0+ App Control Server and 8.7.2+ Windows Agent resolves this issue.

• EP-18203: In 8.9.0 and greater versions of the Windows Agent, the following health check on Windows XP and 2K3 may be displayed:"Severity[Low]: c:\program files\bit9\parity agent\parity.exe is signed but could not check revocation: Error[800B010E]"

  Due to potential SHA-1 collisions, certificate issuers no longer issue SHA-1 certificates. As a result, we've issued our own SHA-1 certificate and we do not have a way to issue CRLs (certificate revocation lists). The issue does not occur on operating systems that fully support SHA-256.

• EP-18204: The signature information of App Control binaries on Windows XP and Windows 2003, may display the following error:"A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file".

  This is due to Windows XP and WIndows 2003 not fully supporting SHA-256 signatures. The timestamping server that we use only signs with SHA-256 or later, and so the OS cannot verify that the file was signed in the validity period of the Carbon Black signing certificate.

• EP-18508: Users may only see one notifier display when an instance of process hollowing is detected and blocked. In this case, two notifiers should display, one blocking the hollowing process and one blocking the hollowed process.

  Even though one notifier displays both processes are still blocked.

• EP-19509: Custom rules are not enforced on WinXP when the DFS Server is from another domain

  Automatic DFS mapping requires the active user to have permissions on the DFS server. Entering separate credentials in explorer is not sufficient.