[gnutls-devel] Fwd: GnuTLS hostname checking bug report

[Nikos Mavrogiannopoulos]

---------- Forwarded message ----------
From: Suphannee Sivakorn <suphannee at cs.columbia.edu>
Date: Thu, Mar 16, 2017 at 5:56 AM
Subject: Re: GnuTLS hostname checking bug report
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
Cc: "George Argyros (Columbia University" <argyros at cs.columbia.edu>,
Kexin Pei <kpei at cs.columbia.edu>, Suman Jana <suman at cs.columbia.edu>,
GnuTLS development list <gnutls-devel at lists.gnutls.org>


Hi Nikos,
thank you for your quick reply! Please see below and feel free to let
us know for any further information.

Thanks,
Suphannee

On Wed, Mar 15, 2017 at 8:52 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> 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.
>

#1. The actual text also includes "or any application-specific
identifier types". As the function gnutls_x509_crt_check_hostname()
also supports IP address identifier, we believe that if IP-address/DNS
in SubjectAltName presents, the check for CN should be skipped. We
also agree that this is very unclear from RFC. After testing with many
implementations, some of them do follow it (e.g., CPython SSL, cURL),
and some of them not (e.g., MatrixSSL, JSSE).


>> 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.

#2. We agree that RFC 6125 nor 5280 does not specify the correct
behavior for matching empty label on wildcard certificate. Undoubtedly
this creates discrepancies. Since the RFC doesn't say, it is not a
violation and therefore up to developer to decide. Unfortunately we
haven't found any exploitable for this case too. We are trying to let
developers know about it.

>
>> 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.
>

#3. That sounds good. We haven't test that version yet. We will report
again when we retest with that expensive check.

>> 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.
>

#4. We have included the test for libraries i.e., OpenSSL, GnuTLS,
MbedTLS, MatrixSSL, JSSE, CPython SSL and applications i.e.,
HttpClient, cURL (default configuration). So far only GnuTLS, MbedTLS
and MatrixSSL have this behavior, while others perform the check
against only IP address in SAN when given IPv4 format string.

Just a little inside info:
OpenSSL lets applications choose identifier type for verification, the
library therefore doesn't encounter this problem. We have also
reported this to MatrixSSL, which the developer has decided to release
a new version with an option flag for selecting identifier type
similar to OpenSSL approach.

MbedTLS does not support IP address certificate, so they do not check
IP-address SAN certificate anyhow.


>> 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