Veritas Backup Exec Remote Agent For Windows Use-After-Free

Veritas Backup Exec Remote Agent for Windows suffers from a use-after-free vulnerability. All versions before Backup Exec 16 FP1, Backup Exec 15 14.2.1180.3160, and Backup Exec 2014 14.1.1187.1126 are affected.

MD5 | a2f19b80d629adbcdd824fab754c16dc

Affected software: Veritas (previously Symantec) Backup Exec Remote
Agent for Windows
Affected versions: All versions before Backup Exec 16 FP1, Backup Exec
15 14.2.1180.3160, Backup Exec 2014 14.1.1187.1126

Vulnerability type: Use-after-free
Impact: Unauthenticated remote code execution as SYSTEM user
Solution: Install the latest version across all hosts with the agent installed

Vendor disclosure:


The Backup Exec Remote Agent for Windows is vulnerable to a
use-after-free in its handling of SSL/TLS-wrapped NDMP connections. If
SSL/TLS is established on a NDMP connection, ended, and finally
re-established, the agent will re-use previously freed SSL/TLS
structures. This allows for remote code execution over an
unauthenticated network connection. (Note: the requirement for
authentication given in the MITRE CVE description is incorrect; no
authentication is required.)


The agent accepts NDMP connections on TCP port 10000. The
vendor-specific `0xF383` NDMP packet type allows for NDMP connections
to be wrapped in a SSL/TLS session. Sub-type `4` initiates the SSL/TLS
handshake; after successfully completing this the client and server
continue the NDMP session through the SSL/TLS session.

The agent makes use of OpenSSL to handle these SSL/TLS sessions. When
a SSL/TLS session is created, the agent creates necessary OpenSSL
structures, including a `struct BIO` from the connection's associated
network socket using `BIO_new_socket`. Upon the end of the SSL/TLS
session, this structure is freed by a call to `BIO_free` through a
call to `SSL_free`.

However, if a SSL/TLS connection is then re-established on the same
NDMP connection, the previously freed `BIO` is re-used in the new
SSL/TLS session even though it is no longer allocated. The `BIO` is
stored during the first connection setup and then retrieved during
second connection setup as a member of the `CSecuritySSLConnection`
class, despite the call to `SSL_free` previously freeing it. This
leads to a use-after-free as the `BIO` contains a pointer to a
structure (`BIO_METHOD *method`) of function pointers that are used to
perform operations such as reading and writing from the wrapped `BIO`
object (in this case, the network socket).

By overwriting the previously allocated `BIO` with controlled data, it
is possible to gain remote code execution when OpenSSL attempts to
call one of these function pointers.

- Matthew Daley

Related Posts