Carbon Black Installer Multiple Vulnerabilities

The CarbonBlack installer package for macOS (CbDefense Install_3.4.3.44 and prior) has been discovered to contain multiple security-related issues.

The installer utilizes insecure directories during the installation process. The two directories in question are "/tmp" (this is a symlink to "/private/tmp" on modern macOS variants) and "/private/var/tmp". The following files make use of these directories during the installation process (primarily in the "preinstall" binary): .cbd, .confer_install_type, cloud.pem, confer.ini, cfg.ini, and dynamic log files. Since these files are all user-readable/writable at this point, they are all vulnerable to manipulation by a local attacker, most prominently, symlink attacks.

As the installer access these files as root and copies their contents into the main application directory later in the process, which are then world-readable, a local attacker can use this vector to copy information into these file from files they would not normally have access to, which they can later read at the new location. For example, an unprivileged user could do something like the following:

while true; do
  ln -f -F -s /some_root_only_file /tmp/cbdefense-install/cloud.pem
done

The above, while inelegant and inconsistent, has two possible outcomes based on the timing of the attack. In the first possible outcome, the installer will simply overwrite whatever the symlink points to. This outcome happens because of the initial copy from the installer to the tmp directory. This could cause system instability and result in a denial of service like condition for the entire host. In the second possible outcome, which happens if triggered after the initial copy, the content of the target file will be copied to "/Applications/Confer.app/cloud.pem" (or whatever directory is configured for the host), which is readable by unprivileged users. This can be used as an information disclosure.

While we were not able to achieve privilege escalation with these vectors during our investigation, we do consider it a theoretical possibility. 

Additionally, the "postinstall" binary contains a buffer overflow due to an unchecked call to "strcpy()" when parsing configuration files. The following is a snippet from our reverse engineering process showcasing problematic logic:

if (config_file[0] == '[') {        // Checks that we're in a config section
  _strcpy(local_438,config_file);   // copies the file (controllable via the above issues) into a buffer whose bounds are not validated

When combined with the attacks above (such as manipulating "confer.ini"), an attacker could use this to execute code in the context of the root user. This attack is exceedingly complicated, however, in terms of timing required (the file must remain valid for a short period before the vulnerable code is executed). While unlikely to be exploited, VMware has opted to fix the issue out of an abundance of caution.