[gnutls-devel] GnuTLS hostname checking bug report

[Nikos Mavrogiannopoulos]

On Tue, Mar 14, 2017 at 7:12 PM, Suphannee Sivakorn
<suphannee at cs.columbia.edu> wrote:
> Dear Sir/Madam,
>
> We are a team of security researchers from Columbia University. As
> part of recent research on SSL/TLS hostname verification, we have
> audited your implementation (GnuTLS 3.5.3) and found 4 behaviors that
> differ from other libraries' implementations. Below we provide
> information from our experiments and findings. Please feel free to
> contact us for more information.

Hello and thank you for your work in identifying these interesting cases.

> 1. Attempting to match CN when any SubjectAltName identifiers present (RFC 6125)
> Section 6.3 of RFC 6125 prohibits clients from attempting to match CN
> if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any
> application-specific identifier types supported by the client. We
> found that GnuTLS violates this requirement. The function
> gnutls_x509_crt_check_hostname(2), which supports hostname
> verification for hostname and IP address, attempts to match
> certificate CN even when there is a subjectAltName identifier
> presents, e.g., IP address. However, the library follows the
> requirement when subjectAltName DNS presents.

That is quite interesting. The actual text of RFC6125 is:
"Security Warning: A client MUST NOT seek a match for a reference
identifier of CN-ID if the presented identifiers include a DNS-ID,
SRV-ID, URI-ID, or any application-specific identifier types
supported by the client."

My understanding of the text is that, the last part of the sentence
implies that the prohibition of falling back to CN-ID matching applies
when SRV-ID and URI-ID are supported. Given that gnutls doesn't
support SRV-ID or URI-ID matching, it falls back immediately after the
DNS-ID is checked. I may be wrong though, and I'm forwarding your
message to the gnutls development list for further discussion.

> 2. Matching wildcard with empty label
> We found that GnuTLS matches with empty label, e.g., matches hostname
> ".aaa.aaa" with certificate commonName(CN)/subjectAltName DNS:
> "*.aaa.aaa". However, the .aaa.aaa is not valid domain name according
> to RFC 1034 which requires each label must be between 1 to 63
> characters long, except the root label.

That is a nice observation. However, since '.aaa.aaa' is already an
illegal hostname addressing this would mean gnutls checking the
application input for having  valid DNS format. I am not sure if we
should go into large extends of verifying application input (e.g., we
also do not check whether the label length is over 63 characters),
unless you believe there are security implications in that; in that
case I'd appreciate if you could expand.

> 3. No hostname validation
> The library attempts to match the provided hostname even when the
> certificate's CN/DNS or the hostname contains one, or more, invalid
> characters. In the context of DNS names, invalid characters are all
> characters outside the range [A-Za-z0-9.-].  For example GnuTLS allows
> wildcard character to be interpreted as a literal character in the
> name check verification. For example, the library will match hostname
> "example.*.com" with certificate CN/DNS "example.*.com", even though
> the wildcard character "*" is not in the valid character set for
> domain names.  An additional example would be matching hostname
> "example.a=.com" with certificate CN/DNS "example.a=.com".

That is related but not identical to the above point. The input to the
hostname validation function is expected to be a valid hostname. If it
is not, indeed undefined results can happen. Said that, you got a
point that having a sanity check on the stored in the certificate DNS
names is a good thing. I believe that's already the case in GnuTLS
version 3.5.9. That version introduced IDNA2008 support and it
performs extensive checks for valid format of DNS names stored in
certificates.

> Ensuring
> that CN/DNS with invalid characters are rejected, will make the
> library more robust against attacks that utilize such characters such
> as the NULL byte injection attacks.

I believe NULL byte injection attacks are explicitly countered.

> 4. Matching IPv4 string hostname with subjectAltName DNS
> We found that giving IPv4 format string as hostname, GnuTLS attempts
> to match this string with DNS attribute in the certificate
> subjectAltName when IP address attribute in the certificate
> subjectAltName does not match or present. Since RFC 1123 allows the
> domain name to be letter or digit, this introduced valid DNS names
> which are identical to IP addresses.

That is an unfortunate but documented behavior for certain broken
situations. See:
http://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fcrt_005fcheck_005fhostname2

It used to be that the DNS field contained IP addresses in some big
PKI deployments. I'd appreciate if you could share your findings on
other implementations for that issue, as it would help us decide
whether to deprecate that behavior.

> The first observation we make is that the set of valid domain names is
> a superset of the set of valid IP addresses. Let assume that attacker
> targets SSL/TLS connections to the server with IP address
> 85.130.200.4. The IP address 85.130.200.4 can be considered as a
> subdomain of the top level domain 200.4. One may point out that .4 is,
> currently, not a valid top level domain. However new top level domains
> are being added frequently upon request. Since there is no fundamental
> restriction in the format of a top level domain, it is completely
> within the realm of possibility that purely arithmetic top level
> domains will appear in the near future. To perform the attack, the
> attacker is generating a certificate for the subdomain of 200.4 [...]

That is certainly a concern.

regards,
Nikos