CVE Vulnerabilities

CVE-2019-12677

Encoding Error

Published: Oct 02, 2019 | Modified: Nov 21, 2024
CVSS 3.x
6.5
MEDIUM
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.x
4 MEDIUM
AV:N/AC:L/Au:S/C:N/I:N/A:P
RedHat/V2
RedHat/V3
Ubuntu

A vulnerability in the Secure Sockets Layer (SSL) VPN feature of Cisco Adaptive Security Appliance (ASA) Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition that prevents the creation of new SSL/Transport Layer Security (TLS) connections to an affected device. The vulnerability is due to incorrect handling of Base64-encoded strings. An attacker could exploit this vulnerability by opening many SSL VPN sessions to an affected device. The attacker would need to have valid user credentials on the affected device to exploit this vulnerability. A successful exploit could allow the attacker to overwrite a special system memory location, which will eventually result in memory allocation errors for new SSL/TLS sessions to the device, preventing successful establishment of these sessions. A reload of the device is required to recover from this condition. Established SSL/TLS connections to the device and SSL/TLS connections through the device are not affected. Note: Although this vulnerability is in the SSL VPN feature, successful exploitation of this vulnerability would affect all new SSL/TLS sessions to the device, including management sessions.

Weakness

The product does not properly encode or decode the data, resulting in unexpected values.

Affected Software

Name Vendor Start Version End Version
Adaptive_security_appliance_software Cisco 9.3 (including) 9.3.3.9 (excluding)
Adaptive_security_appliance_software Cisco * 9.1.7.4 (excluding)
Adaptive_security_appliance_software Cisco 9.2 (including) 9.2.4.8 (excluding)
Adaptive_security_appliance_software Cisco 9.4 (including) 9.4.2.11 (excluding)
Adaptive_security_appliance_software Cisco 9.5 (including) 9.5.2.5 (excluding)
Adaptive_security_appliance_software Cisco 9.6 (including) 9.6.2 (excluding)

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

References