An issue (4 of 6) was discovered in Veritas Enterprise Vault through 14.1.2. On start-up, the Enterprise Vault application starts several services that listen on random .NET Remoting TCP ports for possible commands from client applications. These TCP services can be exploited due to deserialization behavior that is inherent to the .NET Remoting service. A malicious attacker can exploit both TCP remoting services and local IPC services on the Enterprise Vault Server. This vulnerability is mitigated by properly configuring the servers and firewall as described in the vendor's security alert for this vulnerability (VTS21-003, ZDI-CAN-14075).

An issue (3 of 6) was discovered in Veritas Enterprise Vault through 14.1.2. On start-up, the Enterprise Vault application starts several services that listen on random .NET Remoting TCP ports for possible commands from client applications. These TCP services can be exploited due to deserialization behavior that is inherent to the .NET Remoting service. A malicious attacker can exploit both TCP remoting services and local IPC services on the Enterprise Vault Server. This vulnerability is mitigated by properly configuring the servers and firewall as described in the vendor's security alert for this vulnerability (VTS21-003, ZDI-CAN-14074).

An issue (2 of 6) was discovered in Veritas Enterprise Vault through 14.1.2. On start-up, the Enterprise Vault application starts several services that listen on random .NET Remoting TCP ports for possible commands from client applications. These TCP services can be exploited due to deserialization behavior that is inherent to the .NET Remoting service. A malicious attacker can exploit both TCP remoting services and local IPC services on the Enterprise Vault Server. This vulnerability is mitigated by properly configuring the servers and firewall as described in the vendor's security alert for this vulnerability (VTS21-003, ZDI-CAN-14076).

An issue (1 of 6) was discovered in Veritas Enterprise Vault through 14.1.2. On start-up, the Enterprise Vault application starts several services that listen on random .NET Remoting TCP ports for possible commands from client applications. These TCP services can be exploited due to deserialization behavior that is inherent to the .NET Remoting service. A malicious attacker can exploit both TCP remoting services and local IPC services on the Enterprise Vault Server. This vulnerability is mitigated by properly configuring the servers and firewall as described in the vendor's security alert for this vulnerability (VTS21-003, ZDI-CAN-14078).

An issue was discovered in Veritas Backup Exec before 21.2. The communication between a client and an Agent requires successful authentication, which is typically completed over a secure TLS communication. However, due to a vulnerability in the SHA Authentication scheme, an attacker is able to gain unauthorized access and complete the authentication process. Subsequently, the client can execute data management protocol commands on the authenticated connection. The attacker could use one of these commands to execute an arbitrary command on the system using system privileges.

An issue was discovered in Veritas Backup Exec before 21.2. It supports multiple authentication schemes: SHA authentication is one of these. This authentication scheme is no longer used in current versions of the product, but hadn't yet been disabled. An attacker could remotely exploit this scheme to gain unauthorized access to an Agent and execute privileged commands.

An issue was discovered in Veritas Backup Exec before 21.2. The communication between a client and an Agent requires successful authentication, which is typically completed over a secure TLS communication. However, due to a vulnerability in the SHA Authentication scheme, an attacker is able to gain unauthorized access and complete the authentication process. Subsequently, the client can execute data management protocol commands on the authenticated connection. By using crafted input parameters in one of these commands, an attacker can access an arbitrary file on the system using System privileges.

An issue was discovered in Veritas APTARE 10.4 before 10.4P9 and 10.5 before 10.5P3. By default, on Windows systems, users can create directories under C:\. A low privileged user can create a directory at the configuration file locations. When the Windows system restarts, a malicious OpenSSL engine could exploit arbitrary code execution as SYSTEM. This gives the attacker administrator access on the system, allowing the attacker (by default) to access all data, access all installed applications, etc.

An issue was discovered in Veritas InfoScale 7.x through 7.4.2 on Windows, Storage Foundation through 6.1 on Windows, Storage Foundation HA through 6.1 on Windows, and InfoScale Operations Manager (aka VIOM) Windows Management Server 7.x through 7.4.2. On start-up, it loads the OpenSSL library from \usr\local\ssl. This library attempts to load the \usr\local\ssl\openssl.cnf configuration file, which may not exist. On Windows systems, this path could translate to <drive>:\usr\local\ssl\openssl.cnf, where <drive> could be the default Windows installation drive such as C:\ or the drive where a Veritas product is installed. By default, on Windows systems, users can create directories under any top-level directory. A low privileged user can create a <drive>:\usr\local\ssl\openssl.cnf configuration file to load a malicious OpenSSL engine, resulting in arbitrary code execution as SYSTEM when the service starts. This gives the attacker administrator access on the system, allowing the attacker…

An issue was discovered in the server in Veritas Backup Exec through 16.2, 20.6 before hotfix 298543, and 21.1 before hotfix 657517. On start-up, it loads the OpenSSL library from the Installation folder. This library in turn attempts to load the /usr/local/ssl/openssl.cnf configuration file, which may not exist. On Windows systems, this path could translate to <drive>:\usr\local\ssl\openssl.cnf. A low privileged user can create a :\usr\local\ssl\openssl.cnf configuration file to load a malicious OpenSSL engine, resulting in arbitrary code execution as SYSTEM when the service starts. This gives the attacker administrator access on the system, allowing the attacker (by default) to access all data, access all installed applications, etc. If the system is also an Active Directory domain controller, then this can affect the entire domain.