phoning home

[Mark Andrews]

In message <6252777F-F999-4B39-893C-7329E8BA9344 at rfc1035.com>, Jim Reid writes:
> On 12 Jun 2011, at 20:54, Hauke Lampe wrote:
> 
> >> this is slightly tamer than what i'm going to propose for BIND.  i  
> >> want to
> >> be able to send a specific message saying "CERT VU# xyz" if someone  
> >> is running
> >> a known-vulnerable version.  DNSSEC now makes this practical.  but  
> >> it would
> >> be an information leak, since the version number would be part of  
> >> the QNAME.
> 
> Well maybe. But who says the QNAME must be related to the BIND version  
> that issues this lookup?

latest TXT <version list>
supported TXT <version list>		not eol and no known vulnerabilities
9.0.0 TXT <cve list>/"*"/"-"		"*" no longer maintained (N years
					    after eol)
9.4.1 TXT <cve list>/"*"/"-"		"-" no known vulnerabilities.
9.4.2 TXT <cve list>/"*"/"-"
9.8.0b1 TXT <cve list>/"*"/"-"		only listed until end of beta/rc period

> > How about a zone listing vulnerabilities, linked by NSEC?
> 
> This is a Stunningly Bad Idea. DNS RDATA is not a good place to  
> implement linked lists, even though NSEC provides that capability as a  
> side-effect. What is the client expected to do while this "find if  
> I've got any security bugs" quest was under way?
> How many NSECs would an implementation have to traverse before it gave  
> up or decided it didn't have a security hole?
> 
> I'm not convinced that getting BIND to phone home (when? how often?)  
> is worthwhile.

On demand, start up and daily would be what I would recommend.

> First the people who need to do something about old, buggy versions  
> will not see these warnings or do anything about them. They won't be  
> checking their logs. Or know how to switch on this bugfix check. [It  
> would be configurable, right?] These guys already don't visit the ISC  
> web site for info about vulnerabilities or read any of the lists where  
> announcements get made about a security problem. Expecting them to  
> read and act on a message in the name server logs seems optimistic and/ 
> or naive. Unless the server refuses to run until it gets upgraded.  
> Which introduces another set of nasties...

You send email.
 
> Next, what's to be done about vendors who fold their own tweaks into  
> the code? Or mangle the version info to match their own release  
> conventions? Think $LinuxDistro BIND version foo which is actually  
> BIND x.y.z with (some of) the BIND x.y.z security patches applied.

You provide a method for the distro's to exclude "fixed" issues and
a way for it to find all issues that affect the base version.  The
distros patch would include a list of fixed faults.

> Maintaining the DNS infrastructure for security-holes.bind.isc.org (or  
> whatever) will be a problem. This is probably not a big deal, though  
> the long-term consequences could be unpleasant: ISC would be committed  
> to sustaining this domain forever.

We are already committed to maintaining dlv.isc.org just about forever.
This would just be another sub-zone to maintain.
 
> And what happens when lookups for this domain fail because they get  
> blocked at the corporate firewall or when an organisation has an  
> internal root?

They need to rely on other methods.
 
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org