Am I affected?
Description
Improper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex's bundled CA store, to impersonate that host to users who set cacerts_path to a CA store that leaves that CA out.
cacerts_path (HEX_CACERTS_PATH) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. Hex.HTTP.SSL.ssl_opts/1 passes the configured store as the cacerts option, but builds the partial_chain callback from the bundled store whether cacerts_path is set or not. Hex.HTTP.SSL.partial_chain/2 accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn't contain that CA. Hostname verification still applies.
This issue affects hex: from 0.20.2 before 2.5.2.
Technical analysis
Hex.HTTP.SSL.get_ca_certs/0returns the certificates fromcacerts_pathwhen it's set, andssl_opts/1passes them ascacerts.ssl_opts/1setspartial_chainto&partial_chain(Certs.cacerts(), &1), which always uses the bundled store.- When the server's chain doesn't lead to a certificate in
cacerts, OTP callspartial_chainwith the chain.partial_chain/2returns{:trusted_ca, der}for the first certificate whose public key matches a bundled CA certificate, and OTP validates the chain with that certificate as the trust anchor. - Chain validation and the hostname check from
customize_hostname_check/1still run, so the attacker needs a certificate for the requested host that chains to a bundled CA.
Proof of concept
- Create a PEM file that contains only an unrelated test CA certificate and set
cacerts_pathto it. - Open a TLS connection to hex.pm with the options from
Hex.HTTP.SSL.ssl_opts("https://hex.pm"). The handshake succeeds, and the accepted chain leads to ISRG Root X2 cross-signed by ISRG Root X1, neither of which is in the PEM file. - Remove the
partial_chainoption and connect again. The handshake fails withunknown_ca.
Weaknesses & attack patterns
Weakness
CWE-295
·
Improper Certificate Validation
in catalog →
MITRE ↗
Attack patterns
CAPEC-94
·
Adversary in the Middle (AiTM)
MITRE ↗
Users set cacerts_path to limit which CAs can authenticate Hex's servers, for example to their organization's internal CA. Every CA in Hex's bundled store can still authenticate those servers, so a certificate mis-issued by one of those CAs, or obtained through compromised domain validation, lets an attacker on the network path impersonate hex.pm, repo.hex.pm, a self-hosted repository or a mirror. The attacker receives the API keys, OAuth tokens and repository keys Hex sends, and can alter API responses. Registry signatures and package checksums still prevent changes to registry contents and packages.
Affected — Hex Mix Integration Repository ↗
modules · source files · routines
Affected — GitHub / hexpm/hex Repository ↗
modules · source files · routines
Workarounds
There's no Hex configuration that stops the bundled CAs from being trusted.
Configurations
Affects users who set cacerts_path or HEX_CACERTS_PATH to a CA store that leaves out some of the CAs bundled with Hex. Users who don't set it trust the bundled store already and aren't affected.
Solutions
Upgrade Hex to 2.5.2 or later, for example with mix local.hex. With cacerts_path (HEX_CACERTS_PATH) set, Hex then only accepts server certificates that chain to a CA in that file, and it doesn't trust copies of CA certificates sent by the server.
References
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N