Supporting secure DNS in glibc

Posted Nov 18, 2015 23:05 UTC (Wed) by josh (subscriber, #17465) [Link]

Posted Nov 19, 2015 10:50 UTC (Thu) by runekock (subscriber, #50229) [Link]

Posted Nov 19, 2015 14:58 UTC (Thu) by civodul (guest, #58311) [Link]

Posted Nov 19, 2015 18:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Posted Nov 19, 2015 23:09 UTC (Thu) by edmonds42 (guest, #42670) [Link]

Hi,

I have a few brief comments.

It looks like these two proposals come down to implementing what the DNSSEC RFCs call a "Non-Validating Security-Aware Stub Resolver" (the first proposal described in the article) and a "Validating Security-Aware Stub Resolver" (the second proposal). Here are the definitions from RFC 4033:

   Non-Validating Security-Aware Stub Resolver: A security-aware stub
      resolver that trusts one or more security-aware recursive name
      servers to perform most of the tasks discussed in this document
      set on its behalf.  In particular, a non-validating security-aware
      stub resolver is an entity that sends DNS queries, receives DNS
      responses, and is capable of establishing an appropriately secured
      channel to a security-aware recursive name server that will
      provide these services on behalf of the security-aware stub
      resolver.  See also security-aware stub resolver, validating
      security-aware stub resolver.

   Non-Validating Stub Resolver: A less tedious term for a
      non-validating security-aware stub resolver.

   [...]

   Validating Security-Aware Stub Resolver: A security-aware resolver
      that sends queries in recursive mode but that performs signature
      validation on its own rather than just blindly trusting an
      upstream security-aware recursive name server.  See also
      security-aware stub resolver, non-validating security-aware stub
      resolver.

   Validating Stub Resolver: A less tedious term for a validating
      security-aware stub resolver.

The first definition refers to "an appropriately secured channel", which is further mentioned in RFC 4035:

4.9.3.  Handling of the AD Bit

   A non-validating security-aware stub resolver MAY chose to examine
   the setting of the AD bit in response messages that it receives in
   order to determine whether the security-aware recursive name server
   that sent the response claims to have cryptographically verified the
   data in the Answer and Authority sections of the response message.
   Note, however, that the responses received by a security-aware stub
   resolver are heavily dependent on the local policy of the
   security-aware recursive name server.  Therefore, there may be little
   practical value in checking the status of the AD bit, except perhaps
   as a debugging aid.  In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel.

   A validating security-aware stub resolver SHOULD NOT examine the
   setting of the AD bit in response messages, as, by definition, the
   stub resolver performs its own signature validation regardless of the
   setting of the AD bit.

The RFCs generally treat the "stub resolver" and applications that rely on the stub resolver as separate components that communicate via an interface, and this is true enough if you are using high-level interfaces like getaddrinfo(), but in practice on GNU/Linux and *BSD systems this abstraction becomes very leaky when you want to do anything other than an address lookup (A/AAAA). On Linux systems, the DNS "stub resolver" consists of the res_*() functions and related ns_*() and dn_*() helper functions, which are provided by a separate library libresolv, which is shipped by glibc.

glibc's libresolv is very old. As near as I've been able to track down, it's a cut down version of the "libbind" stub resolver that was included with CSRG BSD, BIND 4, BIND 8, and BIND 9 (up until BIND 9.6.0, when it was removed). glibc first(?) imported this code from BIND 4.9.1 in May 1993, and periodically synchronized with the upstream codebase until the last update from BIND 8.2.3-T5B in July 2000, at which point it continued to evolve independently in glibc. This is why if you execute libc.so.6 glibc will print out BIND-8.2.3-T5B as an "available extension". (The upstream codebase is still kicking around; ISC split it out into a standalone "libbind" distribution when it was removed from BIND 9.6.0, and it was later adopted from ISC by the NetBSD project a few years ago where it was renamed to "netresolv".)

(A digression: parts of the nss_dns code in glibc, which interfaces libresolv to the glibc Name Service Switch, is similarly old and descended from CSRG on stone tablets. This code in its modern glibc form is not easy to read; to take a cherry-picked example, this 2007 commit [corresponding bug report BZ#4381] introduced a vulnerability which was later fixed in this 2015 commit, [corresponding bug report BZ#18287] resulting in CVE-2015-1781, which could have been exploited remotely by malformed DNS response packets under certain conditions. If you're a moderately skilled C programmer who only rarely ventures into the glibc codebase, your reaction to reading these diffs will probably be similar to this fellow, or perhaps this one. This code is seriously hard to read. Fortunately, it appears this bug wasn't likely to be exploitable in practice, at least in instances of calling code which were audited. According to Florian Weimer, then of Red Hat Product Security: "This can only happen if these functions are called with a misaligned buffer. I looked at quite a bit of source code, and tested applications with a patched glibc that logs misaligned buffers. I did not observe any such misaligned buffers.")

The res_* interface is not very fun to use. The result returned by the res_query(), res_search(), and res_send() functions is a bare DNS protocol wire-format message which must be parsed by the application. libresolv offers a number of ns_*() functions (ns_initparse(), ns_parserr(), etc.) that don't quite amount to a parser, but are rather a collection of helper functions that can be used to construct a parser. The ns_*() functions aren't fully documented on GNU or even BSD systems, though; the best API reference available is probably contained in chapter 15 of the O'Reilly "DNS and BIND" book. Here is a trivial example I wrote of using this interface to parse a DNS SRV response. Note how the caller is responsible for checking that the resource record is well-formed and for knowing the precise layout of the data fields within the SRV resource record. In practice, the ns_*() functions tend to be avoided by applications that use the res_*() interface to perform lookups. A good example is the Postfix MTA, which uses the res_*() functions to send a query, but implements its own wire-format message parser. Debian Code Search finds only 34 packages with ns_parserr references, though not all of these instances are actual users of the interface.

Taking the Postfix example, Postfix together with libresolv participate jointly in the parsing of the DNS message, and in particular Postfix examines the AD bit, which arguably puts that application code within the boundary of what the DNSSEC RFCs call the "non-validating security-aware stub resolver". RFC 4035 specifically says, "In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf [i.e., the AD bit], except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel." Postfix tries to conform with that "MUST NOT" by warning that it's the sysadmin's responsibility to configure the system's resolver correctly. (BTW, there is a comment in the Postfix codebase that they might make libunbound, a validating stub resolver library, a mandatory dependency, which would allow Postfix to do its own validation.)

Another example is the OpenSSH client on Debian and Fedora systems, which is compiled without ldns support. In order to look up SSHFP records it uses the res_*() interface with RES_USE_EDNS0|RES_USE_DNSSEC and examines the AD-bit, and it also uses its own DNS message parsing implementation rather than relying on libresolv's ns_*() interface.

If I understand correctly, since e.g. Postfix and OpenSSH currently assume the AD-bit is trustworthy, the AD-bit stripping proposal described in this article amounts to declaring that the glibc stub resolver does not always obtain its data from "a trusted security-aware recursive name server via a secure channel", and if there were some way to determine that the system's upstream resolver is both trustworthy and that the system communicates with it over a secure channel, the AD-bit could be unmasked. Both of those determinations are pretty hard to evaluate, and to communicate to relying processes with the existing APIs/ABIs. Especially when those relying processes might use their own stub resolver (e.g., adns, c-ares) and the only ABI you have is the contents of the /etc/resolv.conf file.

The second proposal described in the article appears to be to add a "Validating Security-Aware Stub Resolver" to glibc, which is the "trust, but verify" (i.e., don't trust) mode, where the stub resolver on the end host is responsible for performing the cryptographic validation itself. However, since DNSSEC validation requires obtaining additional DNS records this results in short-lived processes spamming the upstream resolver with more DNS queries. Reducing this query spam requires either a local cache, and/or the deployment of a proposal like draft-ietf-dnsop-edns-chain-query. Moreover, in-process validation would result in pulling in a heavyweight library like libunbound, which may spawn threads, perform long-lived heap allocations for its cache, load hairy crypto libraries like OpenSSL into the process, etc. As a proof-of-concept, a few years ago I attempted an nss-ubdns module for the Name Service Switch that could replace nss_dns and use libunbound rather than libresolv for DNS resolution. This turned out to be very crashy in practice with nontrivial applications like Firefox, and I lost interest in the approach.

There are also developments on the horizon that lean towards having a local daemon on the system: the IETF's DNS PRIVate Exchange (DPRIVE) working group is coalescing around proposals to protect the privacy of the "last mile" of DNS with TLS and/or D(TLS) sessions between stub resolvers and recursive DNS servers. (IANA has provisionally allocated TCP/UDP port 853 for this.) To scale, this is going to require maintaining a long-lived session with the recursive DNS server, to minimize the overhead and latency of TCP and TLS session initiation. That means the end host's stub resolver needs to have a nearby long-lived daemon somewhere between it and the recursive DNS server. Probably that means something like a local unbound instance on the system operating in forwarding mode and speaking the port 853 protocol to its upstream resolver.

Finally, folks writing new applications that want to rely on DNSSEC-authenticated resource records from the DNS are unlikely to want to rely on the old resolver interface, even if eventually bleeding edge versions of the glibc resolver grow the capability to tell the caller that the results are trustworthy. (What do you do if you're running on an older glibc version, or the distro you're running on hasn't set things up properly, or you're on a BSD, etc.) Easier to add an external dependency on something like getdnsapi, which currently only has a libunbound backend but will hopefully have an alternate implementation provided by a library form of CZ.NIC's Knot Resolver.

Posted Dec 8, 2015 21:49 UTC (Tue) by ldo (guest, #40946) [Link]