[Summary of Responses] Bound by Tradition: A sampling of the security posture of the Internet's DNS servers

From: Mike Schiffman (mikeat_private)
Date: Tue Mar 11 2003 - 08:30:17 PST

  • Next message: Martin Schulze: "[SECURITY] [DSA 258-1] New ethereal packages fix arbitrary code execution"

    - Chris Gordon <chris.gordonat_private> has been watching DNS
    traffic at www.dshield.org and was wondering if "something was coming"
    and wanted to know if I had seen anything to indicate a DNS worm or
    virus was propagating. Chris, I have not noticed anything along those
    lines but all I did was actively scan DNS servers and process the
    responses, I did not sift through arbitrary Internet DNS traffic.
    
    - Bill Manning <bmanningat_private> did not find the paper "particularly
    new or that interesting".  He thought it reinforced work done over the
    last six years on the vulnerabilities in the installed base of DNS code.
    
    - Robert Brockway <robertat_private> agreed with the overall
    statement of the paper 100%. "Somewhat OT for your discussion but it is
    high time for organisations to realise why they need geographically &
    logically seperated DNS servers.  The number of organisations with 1 DNS
    server, all the servers on the same subnet, or lame delegations is
    disgraceful.  In the end DNS security must rest on a properly configured
    DNS system."
    
    - Kurt Seifried <kurtat_private> found that the paper agreed with his
    results: "This pretty much parallels the results I got when I did some
    checking into government DNS certains for a large country. I was able to
    do zone transfers for something like 60% of the subdomains (with some
    interesting results, like test-oracle-server.foo), bind versions were
    all over the map, and most were poorly secured if at all, to say nothing
    of the classic "all servers on the same subnet" for a few of the larger
    subdomains. I had them contacted, still no change. Sigh."
    
    - Nicholas Weaver <nweaverat_private> pointed out: "The roots
    really aren't vulnerable to a DDoS:  Yes they are a single point, but
    they handle such little real traffic (mostly garbage) and the responses
    are cached for a long time. It is the gTLDs (eg, the .com nameservers)
    which are vulnerable to a DDoS, and the DDoS would probably be a traffic
    load related attacks."
    
    - Nuzman <nuzmanat_private> wrote "One thing that many corporations
    still overlook is diversity in DNS. Remember Microsoft getting knocked
    off because their DNS servers were all on one subnet (early 2001)? I did
    a survey recently of the largest businesses in WI (whois on domain name)
    and almost half had DNS all in the same subnet... even companies that I
    know have good multi-path Net access.
    Heck, even adding something like granitecanyon.com as a 3rd and/or 4th
    DNS server would be an improvement for some businesses.
    One thing I'd be interested in seeing... what's the penetration of
    non-BIND DNS out there? The company I work for is a MS shop and we use
    Win2k DNS for primary and Sprint for additional secondary."
    
    And last, but not least, David Conrad <david.conradat_private> of
    Nominum:
    
    "Cute title.
    
    In no particular order:
    
    1) You appear to make a big deal out of number of lines of code 
    implying increased vulnerability, but the data you provide shows the 
    opposite -- BINDv9 with 300,000+ lines of code has fewer 
    vulnerabilities than BINDv8 (v2 in particular) with half the lines of 
    code.  Note that these code estimates are most likely misleading as 
    they appear to include the entire source tree and BINDv9 has extensive 
    tests that BINDv8 or 4 never had.
    
    2) Several non-BIND DNS servers respond to CHAOS TXT queries for 
    version.bind as if they were BIND.  To get an accurate assessment of 
    the servers running, more elaborate and sophisticated fingerprinting is 
    necessary.
    
    3) Verisign does not run all the root servers, only two, one of which 
    runs Atlas last I heard.  The do run all the .com/.net gTLD servers.  I 
    believe two are running Atlas now.
    
    4) There are many other DNS servers available today, not just djbdns.  
    NSD, PowerDNS, MaraDNS, and Posadis, are 4 open source implementations. 
      Nominum's ANS and CNS, Microsoft Win2K (and .Net or whatever it is 
    called today) DNS, Incognito's DNS Commander, and Cisco's CNR DNS 
    server are proprietary commercial implementations available for 
    purchase.
    
    5) BINDv9 has never had a arbitrary code executable buffer overflow 
    exploit unlike BINDv8 or BINDv4.  It has, however, has had denial of 
    service vulnerabilities until the 9.2 series, most of which do not 
    appear on ISC's web page.   The 9.0 series, in particular, was 
    susceptible to remote denial of service 'packets of death'.
    
    6) BIND 8.2.7 has no known vulnerabilities so it should be classified 
    as 'safe'.  The difference between the 8.2 series and the 8.3 series is 
    primarily v6 support in 8.3.
    
    7) "Klaatu, Barada, Nikto" is actually from the 1950s movie "The Day 
    The Earth Stood Still".  Sam Raimi stole the line for "Army of 
    Darkness" (and other projects he has done)
    
    8) Your section title "Remediation" makes several assertions without 
    data to back up those assertions:
    * "Poor programming is obviously the main issue enabling the 
    vulnerabilities" -- you provide no data that demonstrates poor 
    programming.  An assertion along the lines of "attempts to integrate 
    code from a wide variety of sources in the traditional open source 
    fashion is the main issue enabling the vulnerabilities" would probably 
    be more accurate.
    * "BIND ... is a perfect example of what happens when security is 
    retrofit as opposed to designed into the product ..." -- you have not 
    documented a basis that there was an attempt to retrofit security into 
    the product.
    
    9) Bill Manning at ISI runs a periodic survey of BIND versions and has 
    been doing so since 1996 or so.  Stating your report "is the first to 
    present substantive proof quantifying just how vulnerable" the DNS 
    infrastructure is ... a bit of a stretch.
    
    10) You mention the root DDoS attacks but they are unrelated to BIND.  
    The attacks didn't even use DNS packets.
    
    11) BIND version 4 continues to get security patches.  It is currently 
    at version 4.9.11 (last I looked).
    
    12) It is a bit misleading to say djbdns has no security 
    vulnerabilities.  While it is true that the component programs that 
    make up djbdns have not had a known vulnerability, the design of djbdns 
    relies on external services (Bernstein recommends rsync over ssh, I 
    believe) to replicate data from the primary to secondaries.  A 
    vulnerability in these external services, mandatory for (the equivalent 
    of) normal zone maintenance data replication with djbdns, would be at 
    least as damaging as a vulnerability in the djbdns package itself.  
    However, it makes it much easier to offer 'security guarantees' since 
    large chunks of functionality are not covered under the warranty (so to 
    speak).  There have been vulnerabilities in ssh since djbdns was 
    released.
    
    13) Stating "BIND is mature" is misleading as BINDv9 was a complete, 
    from the ground up rewrite of BIND sharing no code (except for an 
    optionally compile backwards compatibility stub resolver library that 
    does not link into the server) with BINDv8.  BINDv4 could be called 
    mature.  BINDv8 is arguable.  The large jump in lines of code for 8.2 
    was a result of integration of code from external parties (Intel, 
    Checkpoint, and NAI to name three).  Clearly, given the number of lines 
    of code doubled, the maturity of the code base was reset."
    
    --
    Mike Schiffman, CISSP
    http://www.packetfactory.net/schiffman.html 
    



    This archive was generated by hypermail 2b30 : Tue Mar 11 2003 - 09:38:12 PST