Ticket History #8809: Do not call getaddrinfo() with invalid hostnames

# Fri May 24 01:37:41 2019 Jeffrey Altman <jaltman@secure-endpoints.com> - Ticket created

To:	"krb5-bugs@mit.edu" <krb5-bugs@mit.edu>
From:	Jeffrey Altman <jaltman@secure-endpoints.com>
Subject:	Do not call getaddrinfo() with invalid hostnames
Date:	Thu, 23 May 2019 23:17:43 -0400

Download (untitled) / with headers
text/plain 814B

Download (untitled) / with headers
text/html 2.2KiB

gss-krb5 when passed a two component acceptor name passes the second component to getaddrinfo() to canonicalize it. While it is often the case that the second component of a service name is a hostname, it is not always a hostname. The afs rxgk security class service name is of the form

afs-rxgk/_afs.<cellname>

Names that begin with an underscore are not valid DNS hostnames and should not be passed to getaddrinfo() which will happily issue a query which cannot be successfully resolved. Underscores are valid for SRV and TXT records. They are not valid for A/AAAA/CNAME lookups as performed by getaddrinfo().

Kerberos should validate the names passed to getaddrinfo() to avoid unnecessary network queries and timeouts.

A valid host name only consists of [a-z]{A-Z][0-9] and the hyphen ‘-‘.

# Fri May 24 01:56:12 2019 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'open'

# Fri May 24 01:56:12 2019 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/plain 408B

This seems reasonable. I did a few minutes of research to see if we'd
be breaking any IDN scenarios, and I don't think so. We don't pass
AI_IDN to getaddrinfo(), so getaddrinfo won't be doing any encoding
into ACE, and we obviously don't do our own encoding. An application
could, in theory, encode an IDN to ACE before importing a GSS name, but
if it does that then hostname validation will succeed.

# Tue Mar 31 02:12:18 2020 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/html 718B

On Fri May 24 01:37:41 2019, jaltman@secure-endpoints.com wrote:

Show quoted text

gss-krb5 when passed a two component acceptor name passes the second component to getaddrinfo() to canonicalize it. While it is often the case that the second component of a service name is a hostname, it is not always a hostname.

Apologies for letting this sit for a year and then coming back with an argument, but: does it make sense to use GSS_C_NT_HOSTBASED_SERVICE when the second part of the name isn't a hostname? RFC 2743 section 4.1 is pretty clear that the second part is a hostname. Would it be better to import using GSS_KRB5_NT_PRINCIPAL_NAME?

# Tue Mar 31 15:55:04 2020 ghudson@mit.edu (Greg Hudson) - Comments added

Download (untitled) / with headers
text/html 1.2KiB

Jeff encountered a mail delivery issue updating the ticket; here is his response:

RFC 2743 Section 4.1 states that the second component will be treated as
a hostname regardless of whether or not a DNS lookup succeeds.

   "When a reference to a name of this type is resolved, the 'hostname'
   may (as an example implementation strategy) be canonicalized by
   attempting a DNS lookup and using the fully-qualified domain name
   which is returned, or by using the 'hostname' as provided if the DNS
   lookup fails.  The canonicalization operation also maps the host's
   name into lower-case characters."

In the case of a name which begins with a leading underscore the DNS
lookup is guaranteed to fail.  I will call out two items in the above a
paragraph:

 1. Canonicalization by attempting a DNS lookup is optional.

 2. If the optional DNS lookup fails, the 'hostname' will be used
    as provided.

What I have pointed out in this ticket is that a getaddrinfo() query
will always fail for a name beginning with a leading underscore and that
the failure might take a long time.  Therefore, there is no benefit to
issuing the query and the canonicalization step described in Section 4.1
should be skipped.