GHSA-vvx9-73fr-5jjx

Описание

Summary

PHP's OpenSSL stream peer verification checks the certificate's subjectAltName entries first and, whenever no entry matches, falls back to the Common Name. RFC 6125 requires the CN to be ignored once the certificate presents any service identity, so a certificate carrying a non-matching DNS SAN was still accepted when its CN matched the requested peer_name. A certificate trusted by the client for one name can therefore be used to impersonate another.

Details

php_openssl_apply_peer_verification_policy() tries the SAN list and then unconditionally falls back to the CN:

https://github.com/php/php-src/blob/php-8.5.10/ext/openssl/xp_ssl.c#L635-L641

In the tested build a certificate with CN=victim.test and SAN=DNS:attacker.test was accepted for peer_name=victim.test. A control certificate with CN=other.test and the same SAN was rejected, confirming that acceptance came from the CN and that a SAN mismatch did not suppress the fallback.

The fix makes php_openssl_matches_san_list() report whether the certificate presented a service identity, meaning a DNS SAN, a URI SAN, or an SRV-ID otherName (OID 1.3.6.1.5.5.7.8.7). When one is present and none matched, verification now fails with Peer certificate subjectAltName did not match expected name instead of consulting the CN. Certificates with no service identity at all keep the CN fallback for backwards compatibility.

PoC

Certificate for the accepted case:

The rejected control uses the same file with CN = other.test.

Steps:

1. Create a local CA certificate.
2. Issue one server certificate with CN=victim.test and SAN=DNS:attacker.test.
3. Issue a control certificate with CN=other.test and the same SAN.
4. Serve each certificate in turn from a local TLS server.
5. Run the client with peer_name=victim.test and the CA certificate.

The first certificate prints OK (accepted) and the control prints FAIL.

Impact

A certificate that a client trusts for one hostname can be used to impersonate a different hostname, as long as the attacker's certificate carries the target name in its Common Name. This matters where certificates come from a private PKI, an internal CA, or any environment where an attacker can obtain a certificate whose CN it does not control the SAN for. It affects every client stream that relies on the default verify_peer_name, including file_get_contents(), fopen() and stream_socket_client() over https:// and tls://.