marka at isc.org
Tue Jun 14 01:04:09 UTC 2011
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
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
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-workers