LoadMaster Vulnerabilities

Not vulnerable. LoadMaster does not use any components of the Java Spring Framework. [This is also true of the Kemp 360 Central and Vision products.]

Partially vulnerable. This vulnerability exploits a flaw in the Microsoft Windows Server implementation of HTTP trailer headers which may appear at the end of chunked messages. Because trailer headers are not supported on LoadMaster, non-passthrough Layer 7 services on LoadMaster are not susceptible to exploitation of this vulnerability. For passthrough services, the required remediation is to install the latest updates from Microsoft on all vulnerable servers, or turn off trailer header processing on those servers.  

Not vulnerable. This is a vulnerability in the Oracle Java SE. A successful exploit of this vulnerability can result in unauthorized creation, deletion, or modification of Java SE accessible data. The Oracle Java SE is not present on LoadMaster, which is therefore not vulnerable to this attack. 

LoadMaster is vulnerable to this exploit. The updates listed at left were released on 25 April 2022 to close this vulnerability by upgrading to the OpenSSL release where this issue is addressed (OpenSSL 1.1.1n). Please see the Release Notes for more detail.

CVE-2021-45080

It was possible for a malicious, already authenticated, privileged user to obtain unrestricted access to the VLM disk image and thereby obtain a debug password to the running system. This vulnerability has been closed.

CVE-2021-44228

Not Vulnerable. The LoadMaster and GEO products are not vulnerable to this exploit, as Java is not used by either product. [Please note that the KEMP 360 Central and Kemp 360 Vision products also do not use Java.]

CVE-2021-41069

Validation has been enhanced for the upload of a Virtual Service Template to the system to close a security vulnerability wherein a carefully constructed file can be uploaded as a template and create unwanted files on the filesystem.

An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension, then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration).

In LMOS 7.2.55, OpenSSL is updated to version 1.1.1k which addresses this issue. Also see this support article.

Also note that in LMOS 7.2.55, the default setting for SSL Renegotiation is now disabled.

CVE-2019-1549

By default, LoadMaster is not vulnerable to this exploit since renegotiation is disabled by default in 7.2.55 and above (as you noted below). With renegotiation on, LoadMaster is no more vulnerable than any other network appliance running OpenSSL 1.1.1. This CVE is listed as disputed, per this note: It can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment. Therefore, if you enable renegotiation on LM, you need to configure your back-end servers properly to limit renegotiation.