ARM mbed TLS mbedtls_ssl_get_verify_result() Incorrectly Signed Certificates Vulnerability [CVE-2018-1000520]
CVE Number – CVE-2018-1000520
A vulnerability in the mbedtls_ssl_get_verify_result() function of ARM mbed Transport Layer Security (TLS) could allow an unauthenticated, remote attacker to cause a targeted system to accept an arbitrary Elliptic Curve Digital Signature Algorithm (ECDSA) signed certificate.
The vulnerability exists in the mbedtls_ssl_get_verify_result() function of the affected software and is due to improper validation of signed certificates. An attacker on a peer system could use a negotiated cipher suite of an Elliptic Curve Diffie-Hellman (ECDH) key exchange and Rivest-Shamir-Adleman (RSA) signed certificate (TLS-ECDH-RSA-*) to cause the targeted system to accept an arbitrary ECDSA signed certificate. A successful exploit could be used to conduct further attacks.
Proof-of-concept (PoC) code that demonstrates an exploit of this vulnerability is publicly available.
ARM confirmed the vulnerability; however, software updates are not available.
-
To exploit this vulnerability, the attacker may need access to the same trusted, internal network in which the targeted system resides. This access requirement may reduce the likelihood of a successful exploit.
Reports indicate that this vulnerability may also be present in versions later than mbed TLS 2.7.0.
-
Administrators are advised to contact the vendor regarding future updates and releases.
Administrators are advised to allow only trusted users to have network access.
Administrators are advised to run both firewall and antivirus applications to minimize the potential of inbound and outbound threats.
Administrators may consider using IP-based access control lists (ACLs) to allow only trusted systems to access the affected systems.
Administrators can help protect affected systems from external attacks by using a solid firewall strategy.
Administrators are advised to monitor affected systems.
-
ARM released an issue report at the following link: issue #1561
-
At the time this alert was first published, ARM had not release software updates to address this vulnerability.
Duncan is a technology professional with over 20 years experience of working in various IT roles. He has a interest in cyber security, and has a wide range of other skills in radio, electronics and telecommunications.
I’m a maintainer of Mbed TLS and would like to correct some inaccuracies in this entry.
It’s true that if the negotiated ciphersuite is of type TLS-ECDH-RSA the library still accepts ECDSA signed certificates when it’s intended that it should only accept RSA signed certificates, but, the Mbed TLS library will ONLY accept the certificate if it is signed by the specified trusted CA, regardless of whether it’s ECDSA or RSA. There is no cryptographic or security bypass here – just an application of a different cryptographic algorithm. The substitute certificate has to be legitimate in every other respect.
Where you state “To exploit this vulnerability, the attacker may need access to the same trusted, internal network in which the targeted system resides”, you actually need an equivalent signed certificate to the one you’re substituting, that also has been signed by the CA.
From a security perspective, the advantage to an attacker is only very slight. An attacker could use an ECDSA signed certificate when it isn’t intended, but crucially, the certificate must still be signed properly. That means if, for instance, an attacker didn’t have an RSA certificate, and wanted to spoof a server, they could only replace it with a legitimate, signed ECDSA certificate, but that certificate must still have been legitimately signed by the CA.
On its own – there’s no security bypass here, this issue isn’t exploitable, and needs some other vulnerability to be usable in any sense. On it’s own, it can’t be used to compromise anything.
Hi Thanks for the update, this info came from an external CVE notification. Thank you for taking the time to clarify this.