CVE-2020-36477: Mbed TLS X509 Hostname Verification Bug

Mbed TLS contained a subtle but consequential X.509 verification bug — tracked as CVE-2020-36477 — that allowed the library to compare the expected hostname (the cn argument passed to mbedtls_x509_crt_verify) against any entry in the certificate’s subjectAltName (SAN) extension without checking the SAN entry’s type, enabling a surprising IP-to-hostname impersonation trick under certain conditions.

Background / Overview​

Mbed TLS is a lightweight, widely embedded TLS/SSL library used in IoT devices, networked appliances, and many constrained environments. Its X.509 parsing and hostname-checking code is a core building block for secure client-server authentication in those deployments.
CVE-2020-36477 was introduced because the library’s name-matching routine treated all SAN entries the same: it compared the raw value supplied as the expected name (usually a DNS hostname) to the raw contents of SAN entries regardless of whether those entries were declared as DNS names, IP addresses, or another SAN name type. In practice, that meant an IP address placed into SAN as an iPAddress octet string could be compared byte-for-byte with a DNS hostname string. Because certain ASCII hostnames map directly to byte sequences that look like IPv4 or IPv6 octet arrays, this produced accidental matches — and therefore a possible impersonation vector.
The bug was reported, fixed in a targeted code change in August 2020, and published as part of Mbed TLS release 2.24.0. Multiple downstream advisories and advisories for Linux distributions (Debian, Ubuntu, Gentoo and others) flagged the issue and urged updates. The library maintainers corrected the comparison logic, added tests, and clarified the intended behavior of the API that accepts the expected name for verification.

---

Why this bug matters: the real-world mechanics​

At a technical level, the vulnerability arises from three interacting facts:

• X.509’s Subject Alternative Name (SAN) extension allows multiple name types (dNSName, iPAddress, URI, otherName, etc.). Each SAN entry has an associated type and value encoding defined by RFCs.
• Proper hostname verification must consider the SAN entry type: DNS hostnames are matched by DNS rules and wildcards, while iPAddress SANs are matched against binary representations of the IP address. RFC 6125 and related documents specify these distinctions and different matching semantics.
• Mbed TLS’s older verification implementation compared the expected name value (typically provided as a textual DNS hostname) to any SAN value without first confirming that the SAN entry type matched the expected name’s type. If the expected name’s bytes coincidentally equaled the raw bytes of an IP iPAddress SAN, the library incorrectly treated that as a match.

A concrete (and intentionally simple) illustration from the original issue thread demonstrates the problem: the IPv4 address 97.46.112.108 has four octets whose decimal values correspond to ASCII bytes for the string "a.pl" — 97 = 'a', 46 = '.', 112 = 'p', 108 = 'l'. If a certificate contained an iPAddress SAN for 97.46.112.108 and Mbed TLS was asked to verify the hostname "a.pl" by comparing bytes naively, the bytes would match and the library could be tricked into accepting that certificate for "a.pl" despite the certificate not containing a dNSName SAN for that domain. The attacker would need control of the IP address (or the ability to obtain a certificate for that IP from a CA) to exploit it, but the outcome is improper authentication of an unrelated hostname.

---

Technical analysis: where the check went wrong​

The intended behavior (per standards)​

Standards for TLS hostname verification (RFC 6125 and the PKIX profile) make clear how identity information in certificates should be interpreted:

• If the certificate contains a dNSName SAN entry, that field is the preferred source of identity for a DNS hostname.
• Matching for dNSName entries must follow DNS-like rules (case-insensitive comparison, wildcard handling per defined rules).
• If the expected identity is an IP address, the iPAddress SAN entry — represented as an octet string containing the binary address — must be used and matched as an IP, not a string.
• Implementations should not mix name types when performing comparisons; e.g., do not compare the textual DNS name against the raw octets that express an iPAddress SAN.

These rules are deliberate: a SAN entry’s type is semantically essential to how its value must be compared.

What Mbed TLS did wrong​

The pre-2.24.0 code path that performed name verification used a function that iterated SAN entries and attempted to match the expected name against each SAN value but failed to require type equality before comparison. The implementation compared the bytes held in SAN entries (including iPAddress octet strings) against the expected name’s bytes without normalizing types. With a textual expected name being passed to the check, a byte-by-byte equality check to an iPAddress octet string could succeed by coincidence.
The fix changed the code to:

• Respect SAN entry types: only compare DNS names with DNS SANs and IP addresses with iPAddress SANs (or otherwise follow the spec’s rules).
• Add tests validating that a DNS name does not match an iPAddress SAN and vice versa.
• Improve documentation of the API about the role and acceptable values of the cn parameter.

A pull request that implements this change also added unit tests and backports to LTS branches where required.

---

Exploitation scenarios and real-world feasibility​

Not every mismatch produces a meaningful impersonation risk; exploitation requires several preconditions:

• The target software must use a vulnerable Mbed TLS version (pre-2.24.0) and actually call the hostname/name verification function in the vulnerable fashion.
• The attacker must obtain a certificate containing a SAN entry whose raw encoding equals the expected hostname bytes. The simplest path is obtaining a certificate for an IP address where the IP’s octets align with ASCII characters that form the target DNS name.
• The attacker must control, or otherwise be authorized for, the IP address in question — or obtain a certificate from a CA that will issue certs for an IP address the attacker controls. Some public CAs will issue certificates for IP addresses if proof of control is presented and policies allow it; in private CA environments or misconfigured CAs the threshold may be lower.
• The target client must use textual hostnames (not pre-supplied IPs) and supply the expected name that triggers the vulnerable match.

Given those constraints, the most plausible real-world scenario is:

• Attacker controls an IP A.B.C.D whose four octets correspond to ASCII bytes forming a short domain name (for example, "a.pl").
• Attacker obtains a certificate for that IP from a CA that will issue certs for IP addresses.
• Attacker presents that certificate to a vulnerable Mbed TLS-based client that is verifying "a.pl".
• Because the vulnerable code compares byte sequences across SAN types without checking type, the iPAddress octet string matches the bytes of "a.pl", and the client accepts the certificate as valid for "a.pl".

Practical exploitation depends on how easy it is to find or acquire IP addresses whose octets map to meaningful DNS names, and on CA issuance policies. Those are non-trivial hurdles, but the vulnerability nonetheless violates a core correctness property of certificate hostname verification, and correctness vulnerabilities are critical to address even when exploitation appears somewhat constrained.

---

Risk assessment​

• Scope: This is a protocol-level validation bug inside Mbed TLS — any client or product using an affected Mbed TLS release for server identity verification could be affected.
• Severity: The vulnerability is typically scored as Medium (CVSS v3 around 5.9 in public advisories). That rating reflects both the technical seriousness of misbinding identities and the constraints on practical exploitation.
• Likelihood of exploitation: Moderate-to-low in most internet-facing ecosystems because the attacker needs a matching IP and the ability to obtain a cert for it; however, in controlled enterprise or private-CA environments, the bar can be much lower.
• Impact: Where exploited, the attacker can impersonate another hostname to vulnerable clients, enabling man-in-the-middle or credential phishing attacks that defeat TLS server authentication.

Key systems of concern include:

• Embedded devices with static firmware that use older Mbed TLS (e.g., network cameras, routers, IoT devices).
• Applications that bundle an old library and are slow to update or lack processes for library updates.
• Internal services that rely on private CAs with laxer issuance policies.

---

What was fixed and where​

The Mbed TLS maintainers merged a fix in mid-August 2020 that:

• Ensures name comparisons only occur between matching SAN types (DNS vs IP).
• Adds unit tests to prevent regression.
• Clarifies the documented meaning of the API parameter used for the expected name during verification.

The fix was included in release v2.24.0 and backported into relevant LTS branches. Downstream maintainers for major distributions released packages or advisories instructing users to update their Mbed TLS package to versions containing the fix.
If you run Mbed TLS in any product, the safe decision is to upgrade to a fixed release (2.24.0 or later for the main branch; check your chosen LTS branch for backported patch versions). For platforms that cannot upgrade at the binary level, seeking a vendor patch or applying the upstream patch into your build remains necessary.

---

Mitigation and remediation checklist (practical guidance)​

If you maintain software or devices that use Mbed TLS, follow this prioritized checklist:

• Inventory
• Identify all products and builds that embed Mbed TLS. Pay particular attention to firmware images, device vendors’ SDKs, and statically linked binaries.
• Determine the Mbed TLS version in each product (look for version strings, headers, or built binary symbols).
• Patch / Upgrade
• Upgrade to Mbed TLS 2.24.0 or newer, or apply the vendor-provided backport for your LTS branch.
• If you cannot update immediately, apply the specific patch that enforces SAN-type-aware comparisons. The upstream commits include unit tests that make verification robust.
• Short-term workarounds (not a replacement for patching)
• For clients you control, prefer setting the hostname via the TLS API in a way that forces strict checks (e.g., ensure hostname validation is enabled and uses the standard DNS SAN matching code path).
• Reject certificates that contain unexpected SAN types for the connection context (for example, refuse certificates presenting iPAddress SANs when connecting by DNS hostname).
• Increase monitoring for unusual certificate issuances in your environment and for unexpected TLS endpoints.
• Audit and hardening
• Add unit tests in your app to detect mismatched SAN types and to assert correct verification semantics.
• Where possible, instrument or log the certificate SAN types presented by servers your clients connect to; detect and alert on suspicious cases (e.g., an iPAddress SAN when connecting by DNS).
• For product vendors: ensure your CI includes static analysis and unit tests that validate correct identity matching behavior for certificates.
• CAs and issuance
• If you operate a private CA, verify issuance policies for IP address certificates and consider denying issuance where not strictly needed.
• Monitor the public CT (Certificate Transparency) ecosystem for certificates issued for IP addresses that may correlate with your service names.

---

Developer guidance: safe coding practices for TLS consumers​

• Always call the library API that explicitly sets the expected hostname / identity before initiating the TLS handshake. Many libraries require a separate call to set the TLS SNI and the name used for verification; avoid relying on implicit behavior.
• Use API functions that were designed for hostname verification (e.g., functions that enforce DNS SAN rules) rather than ad-hoc verification code.
• Avoid rolling your own matching logic for SAN entries. Follow RFC 6125 and the PKIX profile rules or delegate to a vetted library.
• Write unit tests that cover unusual SAN combinations: ensure DNS names do not match iPAddress SANs, and that wildcard handling is correct.

---

Operational impact and device lifecycle considerations​

This CVE highlights a recurring operational problem in the embedded space: cryptographic libraries are often embedded into long-lived products and not updated frequently. Even though the fix was merged and released in 2020/2021, devices that shipped older Mbed TLS versions remain at risk if they were never updated.
Operators should:

• Prioritize firmware updates for endpoints that perform server authentication (clients as well as servers that authenticate peers).
• Validate that vendor-supplied firmware includes patched Mbed TLS. Ask vendors for explicit version evidence or for a security bulletin confirming the patch.
• Plan software composition tracking in future products: know which library versions are bundled and ensure a supported upgrade path exists.

---

On public proof-of-concept (PoC) reports — a caution​

Some third-party vulnerability aggregators and feeds report the presence of public proof-of-concept exploits for CVE-2020-36477. While public PoCs can raise urgency, independent verification is important. Aggregator claims may point at proof-of-concept code hosted in various repositories, but authoritative proof — especially widely used, weaponized code — was not prominent in primary vendor channels at the time of disclosure.
Treat third-party PoC claims with caution: they can be useful for reproducing the bug for testing, but do not assume active wide-scale exploitation unless monitored telemetry or incident reports indicate otherwise. In other words, address the bug as a correctness flaw that undermines authentication guarantees regardless of immediate exploitation evidence.

---

Broader lessons for certificate validation​

CVE-2020-36477 is an instructive example of how small semantic errors in protocol parsing yield serious authentication failures. Key takeaways:

• Type matters: certificate fields are typed values — you must respect those types, not coerce values across types and compare raw bytes.
• Correctness beats cleverness: ad-hoc or overly generic comparison routines are brittle when RFC-defined distinctions exist; always implement the specification’s intended semantics.
• Tests prevent regressions: unit tests that expose the faulty comparison scenarios (DNS name vs iPAddress SAN) are essential to prevent reintroduction of the bug.
• Upstream patching and timely distribution matter: centralized fixes are only effective if downstream consumers — device vendors, distro maintainers, application maintainers — distribute and install them.

---

Quick reference: what to check right now​

• Does any product you maintain statically link Mbed TLS < 2.24.0?
• Does that product perform hostname verification using mbedtls_x509_crt_verify or equivalent?
• Are there any internal CAs or issuance policies that permit certificates for IP addresses without strict controls?
• Can you push a firmware/library update to affected devices — and if not, can you implement a runtime mitigation such as rejecting unexpected SAN types?

If the answer to any of these is “yes,” prioritize a remediation plan now.

---

Conclusion​

CVE-2020-36477 exposed a correctness flaw in Mbed TLS’s hostname verification: the library compared the expected common name against entries in the certificate SAN extension without respecting the SAN entry type. The result is a class of impersonation risk where an attacker who can control or obtain a certificate for a particular IP address could — by exploiting coincidental byte equality — impersonate a hostname to a vulnerable client.
The fix is straightforward and upstream: ensure SAN comparisons are type-aware, and upgrade to the patched library release (Mbed TLS 2.24.0 or later, or appropriate backports in your LTS branch). The practical exploitation burden moderates the immediacy of emergency response in many internet-facing contexts, but the security principle at stake — correct binding of identity values — is foundational. Operators, product vendors, and developers should treat this as a corrective and preventive lesson: treat certificate fields with their full semantic meaning, automate composition and dependency tracking, and make patching and secure-aging of cryptographic components part of your product lifecycle.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center