re: djbdns is not free

On Thu, 2004-12-02 at 16:47 -0800, william(at)elan.net wrote:

Having had the pleasure of seeing these kind of debates on other lists 
several times (which made those lists unusable for at least a week) can
I ask that participants please do not engage in the following debates:

 1. BIND vs DJBDNS


There is no need for a debate when the answer is so clear:

============ ROUND 1: BIND vs DJBDNS ==================================

How many LoC (w/out comments) in DJBDNS?     :   9,932 lines
How many LoC (w/out comments) in BIND 9.2.2? : 204,970 lines

Security Guarantee in DJBDNS? : Yes, $500 USD (unclaimed)
Security Guarantee in BIND?   : No.

How many public exploits for DJBDNS? : 0
How many public exploits for BIND?   : 19+

The NIST ICAT search reveals 55 "Medium to High" BIND
exploits: http://icat.nist.gov/icat.cfm?function=results&startrow=1


============ ROUND 1: SendMail vs. qmail ==============================

How many LoC (w/out comments) in qmail?    :  14,724 lines
How many LoC (w/out comments) in Sendmail? :  87,118 lines

Security Guarantee in qmail?    : Yes, $500 USD (unclaimed)
Security Guarantee in SendMail? : No.
 - http://cr.yp.to/qmail/guarantee.html

How many public exploits for qmail?    : 0
How many public exploits for SendMail? : 28

The NIST ICAT search reveals 28 "Medium to High" SendMail 
exploits: http://icat.nist.gov/icat.cfm?function=results&startrow=1

14 serious vulnerabilities discovered within the SendMail codebase
between 1996 and 1997: http://cr.yp.to/maildisasters/sendmail.html


============ BIND Security Explored... ================================

  BIND SECURITY ADVISORIES:
  -------------------------

 - http://www.isc.org/index.pl?/sw/bind/bind-security.php

  1996/97:
  --------
    |-> http://www.cert.org/advisories/CA-96.02.bind
    |--> http://www.cert.org/advisories/CA-1997-22.html (1)
    --> http://www.cert.org/advisories/CA-1996-04.html (1)

  1998:
  -----
    --> http://www.cert.org/advisories/CA-1998-05.html (3)

  1999/2000:
  ----------
    |-> http://www.cert.org/advisories/CA-1999-14.html (6)
    |--> http://www.cert.org/advisories/CA-2000-03.html (REITERATED)
    --> http://www.cert.org/advisories/CA-2000-20.html (2)

  2001:
  -----
    --> http://www.cert.org/advisories/CA-2001-02.html (4)

  2002:
  -----
    --> http://www.cert.org/advisories/CA-2002-15.html (1)
    --> http://www.cert.org/advisories/CA-2002-19.html (2)
    --> http://www.cert.org/advisories/CA-2002-31.html (4)

  2003:
  -----
    --> http://www.cert.org/advisories/CA-2003-01.html (1)


Just how bad is BIND's security track record? :
-----------------------------------------------

  CERT Summary* ranking:
  ----------------------

  #1 2/Q 1998 http://www.cert.org/summaries/CS-98.06.html
  #3 3/Q 1998 http://www.cert.org/summaries/CS-98.07.html
  #3 4/Q 1999 http://www.cert.org/summaries/CS-99-04.html
  #1 2/Q 2000 http://www.cert.org/summaries/CS-2000-02.html
  #4 4/Q 2002 http://www.cert.org/summaries/CS-2002-04.html

  June 28, 2002 - Buffer Overflows in Multiple DNS Resolver Libraries
    - http://www.cert.org/advisories/CA-2002-19.html

  - This was probably one of the single largest exploits (as regards
     vendor** impact and potential damage) the Internet has ever seen.
     In plain English, it was fucking HUGE.

  - libraries affected (_HINT_ DJBDNS is _NOT_ in this list)?
    - ISC BIND DNS resolver library (libbind)
    - BSD DNS resolver library (libc)
    - GNU DNS resolver library (glibc)
  
  May 21, 1998 - BIND gets a SPECIAL CERT notice its so problematic:
    - http://www.cert.org/summaries/CS-98.04.html

  May 28, 1998 - BIND gets ANOTHER special notice, more exploits!
    - http://www.cert.org/summaries/CS-98.05.html


Other DNS related GOOD reading:
-------------------------------

  Compare BIND vs DJBDNS with respect to 'ease of use':
  - http://cr.yp.to/djbdns/blurb/easeofuse.html

  Read up about DJBDNS security:
  - http://cr.yp.to/djbdns/blurb/security.html

  Trouble with DNS:
  - http://www.spirit.com/Network/net0600.html

* The CERT Coordination Center periodically issues the CERT Summary to
draw attention to the types of attacks currently being reported to our
incident response team, as well as to other noteworthy incident and
vulnerability information. The summary includes pointers to sources of
information for dealing with the problems discussed here.

** With respect to the number of Vendors affected by this massive bug
which by my research indicates that it was revealed 2 full years prior
and even fixed within OpenWall affected all of the following Vendors:

Caldera
Compaq Corp.
Conectiva
Cray Inc
Debian
FreeBSD
GNU (glibc)
Guardian Digital
Hewlett-Packard Co.
IBM Corp.
Juniper Networks
MetaSolv
MandrakeSoft
NetBSD
Network Appliance
Nortel Networks
OpenBSD
OpenPKG
Red Hat
Secure Computing Corporation
Sendmail (this ALONE is huge)
Sun Microsystems (SOLARIS)
SuSE
Trustix

and of course:

Internet Software Consortium (ISC)
- All versions of BIND 4 from 4.8.1 prior to BIND 4.9.9 are vulnerable.
- All versions of BIND 8 prior to BIND 8.2.6 are vulnerable.
- All versions of BIND 8.3.x prior to BIND 8.3.3 are vulnerable.
- BIND versions BIND 9.2.0 and BIND 9.2.1 are vulnerable.
- The status of BIND 4.8 is unknown, assume that it is vulnerable.
- BIND versions BIND 9.0.x and BIND 9.1.x are not vulnerable.

As you can see, this bug had been around a _LONG_ time.

2. Linux vs FreeBSD


I'm not touching the Linux vs FreeBSD argument with a ten foot pole,
instead I'll stipulate that OpenBSD (by reason of security) is better
than both, or perhaps (by reason of the desktop and driver support)
Linux is clearly better than any other alternative.

And for the record, people who state that DJBDNS is not free are
extremely wrong.  The software is quite literally free.  The only
argument people come up with is with respect to the LICENSE or rather,
the lack thereof.  That being said, the VAST majority of those who slag
djbdns are simply ignorant souls spouting off regurgitated nonsensical
FUD.

People who claim that they can not or will not work with either qmail or
djbdns are simply being difficult likely because they have already
invested much time in understanding either BIND or Sendmail or other
MTA. 

DJB States himself:

Note to programmers: You can and should switch from libresolv to the
djbdns client library, which has always been covered by the djbdns
security guarantee. I've put the .[ch] files (dns.h, dns_dfd.c,
dns_domain.c, dns_dtda.c, dns_ip.c, dns_ipq.c, dns_mx.c, dns_name.c,
dns_nd.c, dns_packet.c, dns_random.c, dns_rcip.c, dns_rcrw.c,
dns_resolve.c, dns_sortip.c, dns_transmit.c, dns_txt.c) and all
necessary lower-level .[ch] files into the public domain.


Placing documents in the public domain:
 - http://cr.yp.to/publicdomain.html

Software User's Rights:
 - http://cr.yp.to/softwarelaw.html

What does all this mean for the free software world? Once you've
legally downloaded a program, you can compile it. You can run it. You
can modify it. You can distribute your patches for other people to
use. If you think you need a license from the copyright holder, you've
been bamboozled by Microsoft. As long as you're not distributing the
software, you have nothing to worry about.


So what if you are a distributor?
 - http://cr.yp.to/qmail/dist.html

I often hear people complain because DJB stipulates that his software
(to be distributed) MUST be installed in specific location by reason of
cross platform compatibility, and I couldn't agree more.  He has as
usual, an entire page dedicated: http://cr.yp.to/compatibility.html

Exception: You are permitted to distribute a precompiled var-qmail
package if (1) installing the package produces exactly the
same /var/qmail hierarchy as a user would obtain by downloading,
compiling, and installing qmail-1.03.tar.gz, fastforward-0.51.tar.gz,
and dot-forward-0.71.tar.gz; (2) the package behaves correctly, i.e.,
the same way as normal qmail+fastforward+dot-forward installations on
all other systems; and (3) the package's creator warrants that he has
made a good-faith attempt to ensure that the package behaves
correctly.


Wow that doesn't seem unreasonable, or impossible.  The Linux and other
distributions who refuse to work with qmail/djbdns are doing so because
they have either been repeating FUD so long they have forgotten what
their issue was but don't want to look bad by changing their tune now,
or because they have their own agenda (ie: own MTA package they wish to
push).

(1) Binary package must retain hierarchy
(2) Must behave correctly on all architectures/systems
(3) Package creator agrees to make a good-faith attempt to ensure the
    above.

Wow, when you actually _READ_ documentation its amazing how SIMPLE the
issues really are and you can see how stupid and stubborn those
representing the various Distributions that lament about non-existent
license issues are being.

It is not acceptable to have qmail working differently on different
machines; any variation is a bug. If there's something about a system
(compiler, libraries, kernel, hardware, whatever) that changes qmail's
behavior, then that platform is not supported, and you are not
permitted to distribute binaries.


Building binary distributions:
 - http://cr.yp.to/qmail/var-qmail.html


Cheers,

James


-- 
James Couzens,
Programmer
                                                     ( ( (      
      ((__))         __\|/__        __|-|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

signature.asc
Description: This is a digitally signed message part