Re: how to get people to upgrade? (Re: The weak link? DNS)
> Isn't the problem with this that in order to get the code out, people need > to upgrade and you therefor risk ending up with only notifying the people > that upgrade anyway? eventually a hard drive fails or the operating system is replaced, and then a BIND upgrade happens as a side effect. statistically this takes between five and ten years for a server whose operator doesn't read CERT advisories. so while the opportunity isn't as frequent as i'd like, it does occur, and i'd like to slip in some logic that makes subsequent upgrades more frequent. (several nanoggers have pointed out that the trouble is human nature, not technology, but that doesn't mean we can't make it easier to do the right thing.)
Re: how to get people to upgrade? (Re: The weak link? DNS)
so here's a proposal. we (speaking for ISC here) could add a config option (default to OFF) to make bind send some kind of registration packet at boot time, containing an e-mail address for a technical contact for that server, and perhaps its hostname as well. the destination would be configurable, and the format would be open, and we would include in the distribution a tool capable of catching these. any campus/WAN admin who wanted to run their own "BIND registration system" could do so. anyone who wanted to simply config their server to send registration data to ISC could do so. for data received at ISC, we'd (a) keep it completely private other than public statistics, (b) clean it of obvious trash (some people will sent registration data for [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact information only in the event that a security defect discovered in that version. remember, the default would be OFF. Isn't the problem with this that in order to get the code out, people need to upgrade and you therefor risk ending up with only notifying the people that upgrade anyway? - kurtis -
Re: how to get people to upgrade? (Re: The weak link? DNS)
Charles Sprickman wrote: On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: One obvious problem with this would be that certain vendors prefer to backport security fixes to older versions rather than test and release new versions...so an insecure-looking version string may actually have had fixes applied. I think you're talking about RedHat, right? What other vendors take this approach? I know that at a recent job I set out to scan for what versions of things were running on a bunch of boxes, and all the RedHat boxes were showing as running vulnerable versions of OpenSSH. Debian does as well. Since they run 3 different primary release branches (stable, testing, unstable), they often backport security fixes onto the stable branch without introducing additional functionality from later revisions that would be introduced via the unstable and then testing branches. For example, I'm running sendmail 8.12.3/Debian-5 which is security patched up to sendmail version 8.12.8. However, the current testing version is 8.12.6/Debian-7 and the unstable version is 8.12.8/Debian-2. While personally I think this is a bogus way to manage security fixes, there are probably many many RedHat boxes out there running BIND. Short of pointing out the error of their ways or expecting them to roll something into their own patches to fix the notification system, how would you handle that? I mean, at least on the ssh thing, they didn't even change the version string one bit, not even a 'rh-p1' or something. So as far as your scanner knows, and as far as the script kiddies know, you're running a vulnerable version. Actually, it's a very good way to run a stable environment and still get the benefit of fixes that address security or severe operational issues. In fact, the packages with the fixes were available the morning after sendmail 8.12.8 was posted and the CERT advisory went out. I had it installed by the afternoon. Can't speak for how RH handles their versioning, but as you can see above, Debian includes the source version on which a package is based plus a revision to indicate additional changes specifically added for Debian. It makes it very easy to keep track of what I have installed even if kiddie scripts think I'm running downrev versions (which I'm not). == bep
Re: how to get people to upgrade? (Re: The weak link? DNS)
SL> Date: Thu, 27 Mar 2003 09:55:08 +1200 (NZST) SL> From: Simon Lyall SL> I'm also worried about any concept of trying to "force" SL> people to upgrade, even with bind I use some features (namely SL> an external named-xfer program) of bind v8 that arn't SL> available in bind v9 . For the servers which I need this on I I'm curious... why not use "dig @wherever zone.example axfr" instead? SL> run bind 8.3.3 (Vendor backported with the 8.3.4 fixes) of SL> copy the named-xfer program over to the bind 9 box. Agreed re the hazards of being heavy-handed. However, I'm sure there would be those who disabled the automated checkup... the question is, would they be the crowd for whom the approach in question was intended? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > One obvious problem with this would be that certain vendors prefer to > backport security fixes to older versions rather than test and release > new versions...so an insecure-looking version string may actually have > had fixes applied. I think you're talking about RedHat, right? What other vendors take this approach? I know that at a recent job I set out to scan for what versions of things were running on a bunch of boxes, and all the RedHat boxes were showing as running vulnerable versions of OpenSSH. While personally I think this is a bogus way to manage security fixes, there are probably many many RedHat boxes out there running BIND. Short of pointing out the error of their ways or expecting them to roll something into their own patches to fix the notification system, how would you handle that? I mean, at least on the ssh thing, they didn't even change the version string one bit, not even a 'rh-p1' or something. So as far as your scanner knows, and as far as the script kiddies know, you're running a vulnerable version. Charles > -- > Jon Lewis [EMAIL PROTECTED]| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003, E.B. Dreger wrote: > PV> From: Paul Vixie > PV> appealing, but i'm more concerned about MIM when fetching > PV> update information than i am with simply registering package > PV> version numbers, hosts, and e-mail addresses. > > Distribute BIND with public key. Updates are encrypted or signed > with its counterpart. But don't distributors already provide this service? Several Linux distributions (at least Redhat and Debian) and Unix companies (Sun at least) already provide [semi-]automatic updates of packages like bind. Just look at the vendor list in the average CERT notice. Someone who downloads, compiles and installs bind directly from the ISC is already indicating that they want to go beyond the safe vendor supplied version thats good-enough for 99% of people. I'm also worried about any concept of trying to "force" people to upgrade, even with bind I use some features (namely an external named-xfer program) of bind v8 that arn't available in bind v9 . For the servers which I need this on I run bind 8.3.3 (Vendor backported with the 8.3.4 fixes) of copy the named-xfer program over to the bind 9 box. -- Simon Lyall.| Newsmaster | Work: [EMAIL PROTECTED] Senior Network/System Admin | Postmaster | Home: [EMAIL PROTECTED] Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Re: how to get people to upgrade? (Re: The weak link? DNS)
PV> Date: 26 Mar 2003 21:22:59 + PV> From: Paul Vixie PV> having the server check for updates and issue local mail is This assumes the configured notification email address remains valid, and the recipient doesn't sort them into a "I'll get around to it" folder. PV> appealing, but i'm more concerned about MIM when fetching PV> update information than i am with simply registering package PV> version numbers, hosts, and e-mail addresses. Distribute BIND with public key. Updates are encrypted or signed with its counterpart. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: how to get people to upgrade? (Re: The weak link? DNS)
i see that a lot of folks are responding publically. sorry to spawn a thread.
[EMAIL PROTECTED] (Niels Bakker) writes:
> So how much would this differ from `make install' running this shell script?
most bind installations are prefab -- the come with the operating system and
there's no "make install" done after the host has a name.
[EMAIL PROTECTED] ("Kuhtz, Christian") writes:
> Administrator inertia is the root cause. I don't see how an automatism such
> as the one described changes human behavior. And unless you change that
> inertia, no amount of notification, databases, registries, yada yada yada
> will make any difference.
this argues for time bombs, where the software will stop working after it
detects some condition (too much time has passed, or an advertisement for
newer software is seen, or a vulnerability notice is seen). this would be
wildly unpopular, contrary to the open source philosophy, and never adopted.
[EMAIL PROTECTED] (Pedro R Marques) writes:
> If you want to address this issue my suggestion would be to make BIND
> automatically update itself... and option that needs to default to ON
> and that can be disabled in managed systems where admins are expected
> to read CERT and act upon it.
this solution implies a trust relationship between a server operator and the
software provider which in fact never exists in reality. even my microsoft
sysadmin friends carefully eyeball any "software update" patch before they'll
put it on production iron. then there's the local customization issue -- and
the binary problem, since many name server hosts do not have compilers. again
this would be contrary to the open source philosophy.
***
i don't want to have this be bimodal (run binaries from someone you're
required to trust, or else run source and be out of date most of the time)
since neither mode is interesting or useful.
i do agree that other open source packages (openssl for example, or apache)
would benefit from a good answer to the "how to get folks to upgrade"
question. however, i'm not sure a single answer will fit all packages.
having the server check for updates and issue local mail is appealing, but
i'm more concerned about MIM when fetching update information than i am with
simply registering package version numbers, hosts, and e-mail addresses.
--
Paul Vixie
how to get people to upgrade? (Re: The weak link? DNS)
> what i really want to talk > about is: how to get people to upgrade their software when defects > are found. > > sending out announcements through CERT and the bind-announce m/l > isn't working. Paul, I seems to me that you are assuming that the problem is not enought information gets to system admins... that may be the case in some instances, but it is my belief that the majority of the cases have to do with the fact that systems are not administered. i.e. they where setup once and there are assumed to be running without need for maintenance. imho, this is a very reasonable expectation... unfortunatly most software is not really up to what people expect in this regard. If you want to address this issue my suggestion would be to make BIND automatically update itself... and option that needs to default to ON and that can be disabled in managed systems where admins are expected to read CERT and act upon it. This is sort of the direction other systems are taking... microsoft, which is quite competent on the consumer market, tends to have this automated update tools that can be turned off but are a pain to do so. The result is imperfect but imho better than what would be without such tools. I'm afraid that BIND is currently a consumer tool also and that you should not expect an administrator to be present, even if someone was around to initialy setup the system. Pedro.
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003 08:14:45 PST, [EMAIL PROTECTED] said: > > What are you talking about, DNS check option will work great for BIND, > I mean if BIND can not get to the root server and thereafter to ISC, you > don't have to worry about it getting hacked, its probably not connected to Keep in mind that the *really* damaging security incidents tend to be the ones with skilled and/or insider attackers. And if you've scored some secretary's PC inside the corporate net, a DNS server inside the net (and unable to contact the outside world) makes a GREAT way to leverage the foothold pgp0.pgp Description: PGP signature
RE: how to get people to upgrade? (Re: The weak link? DNS)
> CK> The way I see it, the issue isn't that there aren't enough > CK> notifications of BIND vulnerabilities. > > Perhaps. But how much is enough? Current notification levels > certainly get a fair number of admins to upgrade. Feel free to elaborate on where you think gaps exist.. > CK> Administrator inertia is the root cause. I don't see how an > CK> automatism such as the one described changes human behavior. > CK> And unless you change that inertia, no amount of > CK> notification, databases, registries, yada yada yada will make > CK> any difference. > > Correct. Human behavior won't change. The pain must exceed the > inertia. I'm always open to suggestions. Let's just suppose for a moment that pain is in fact the right approach. How do you create such 'pain'? Spamming admins with (even more) emails is a bad idea, IMHO. I'm sure it'll catch some of those who enable the feature it, but will it really make that much of a difference? For example, I can't think of a precedent for self-updating software that works (well), especially with the high degree of customization available in BIND. Until we find that holy grail, IMHO, the most you can do is make an update readily available and tell people about it. Thanks, Christian * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
Re: [Re: how to get people to upgrade? (Re: The weak link? DNS)]
On Wed, 2003-03-26 at 10:52, Joshua Smith wrote: > > don't foget to include some useful/helpful comments regarding where to > look for more info Yes, the TXT record would inlcude the entire text of the security notice (hmm... how big can TXT records be?) or at least a URL. > i like this idea better, and every little bit helps, but i still have > some reservations: > for the install-and-forget crowd (it is runnning right - well then why > would i want to mess with it), i don't know that they would see the > periodic messages, know how to act on them (although i am sure that very > detailed instructions could be included in each email), or care to act on > them. unless there is a blinking icon in the 'taskbar' that they click > on, and then magically when the machine has rebooted, they are up2date > with everything, i have doubts that it would work for a lot of the > servers out there Ideally, you would get a mild electric shock from your keyboard if you were running software that had known security problems. Not enough of a shock that would numb your hands (you need them to upgrade!) or send you into cardiac arrest, but just enough that using a computer would be uncomfortable enough so that you would apply security patches in a timely manner. However, the technical and legal issues are unsolvable (I'm fine with the moral/ethical issues here) so I didn't mention it before. Seriously, you can do only so much to *force* people to apply security patches. Basically, when it comes to security patches, there are two classes of admins, the kind that do hear about security advisories and the kind that don't. For those admins that do hear about security advisories there are going to be some admins that don't apply security patches because they just don't care. There are also going to be some that don't apply security patches because they don't know how and don't care enough to learn how. There's not much we can do about those people. What we CAN so is to reduce the number of people that don't hear about security advisories. Web pages, CERT mailing lists, etc. don't reach enough people partly because people don't know about them or don't have the time to check a bazillion web pages or read a bazillion mailing list posts that talk about software that they don't even use. However, if MY DNS server started emailing ME, I'd be a little more likely to sit up and take notice and maybe do something about it. > (besides, how will any of this prompt those whom are > currently out of date to upgrade?) Unfortunately, any proposal like this can only affect future versions of software. Fortunately, most systems get upgraded eventually (although it could take years, maybe decades). Jeff
RE: how to get people to upgrade? (Re: The weak link? DNS)
JL> Date: Wed, 26 Mar 2003 13:00:57 -0500 (EST) JL> From: Jon Lewis JL> How hard would it be to have bind do some sort of secure.bind.isc.org JL> query at start-up or perhaps even periodically and have it log lots of JL> warnings or refuse to run if the query comes back and tells it the local JL> version has been deferred due to security updates? One obvious problem Not hard. Again, I'm in favor of refusing to run... I've encountered waaay too many "I click and it works" people. JL> with this would be that certain vendors prefer to backport security fixes JL> to older versions rather than test and release new versions...so an If they're backporting, they can add their own checks. If they break the version checking, then they become the vendor with the broken software. JL> insecure-looking version string may actually have had fixes applied. JL> Perhaps the query could be for a timestamp that's defined in the source JL> with the assumption that any code older than the most recent security JL> update must be insecure. This would make a good second/additional/whatever check. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: how to get people to upgrade? (Re: The weak link? DNS)
: Correct. Human behavior won't change. The pain must exceed the : inertia. : : Sounds familiar. Have we seen this before? : : Outdated bogon filters... old software... spam... needless route : deaggregation... broken smurf filters... ingress/egress : filtering... router> en Password: router# conf t router(config)# force-conformity-or-else-great-pain router(config)#^Z router# wr mem router#.Write startup-config in progress. .Write startup-config done. router#exit router>exit It truly is the only answer. It's how I handle things on my network. Make it painful and they remember. Otherwise they don't. Period. ;-) scott
Re: how to get people to upgrade? (Re: The weak link? DNS)
What are you talking about, DNS check option will work great for BIND, I mean if BIND can not get to the root server and thereafter to ISC, you don't have to worry about it getting hacked, its probably not connected to internet. And dns already provides ability for ISC to have multiple diverse dns servers in different parts of the world in case you can't get to one of them, so access to these TXT records is assured. And I really do like how Jeff finished with good example what I had in mind in my original email. I still think it might be worth it to ask for email administrator email address during setup and have that added to named.conf as its own special parameter and when its not present then email can go to root or postmaster or possibly hostmaster address from the first zone listed (I'm not sure which is better...) and this system also has to be presented to the user (possibly as default on option), but they must also know what the sytem would be doing (i.e. that you for example will have list of their ips) as some already expressed privacy concerns on this being done automaticly without turn-off option. On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > > > The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I have a better idea. > > ISC could set up a web page that would contain security/bug advisories for > every version. In order to make it easier for people to find this web > page, it could be listed in various directories such as CERT. And it could > also be put into search engines so that someone could go to Google, type > in "BIND bug site:isc.org" and click "I'm Feeling Lucky". > > > yadda yadda yadda... > > Indeed! > > Let's face it folks, DNS is not the tool of choice for publishing anything > other than the mapping between hostnames and IP addresses. > > For some things the web is better. For others LDAP is better. And for the > problem that Paul mentioned at the beginning there is only one solution; > the press. > > The fact is that Paul wants to catch the attention of people who aren't > paying attention right now. He has stated that email notices don't work > and we can assume that the BIND security web page, and CERT's web pages > also don't work. No, there is only one thing Paul can do right now. > > a. Collect some realistic numbers as to the number of DNS servers that are > vulnerable to the various exploits. Ask people who do network scanning to > provide some statistics on what they see and scale them up according to > the number of hosts in the host-count database. For example, assume that > someone has scanned N hosts and discovers that N/10 are running BIND and > that 40% of those are vulnerable. Also assume that the hostcount shows 20 > million hosts in the world. Infer from this that there are 2 million BIND > servers and that there are 800,000 vulnerable ones. But do the > calculations with some real data, not my example figures. > > b. Write a press release with the following headline: > > N Thousand Internet Servers Suffer Same Fate as Iraqi Server > > Or maybe write some variation on this but keep it scary and keep Iraq in > the headline. The body of the press release should explain the attacks > that the Iraqi server was suffering from, then point out how many other > servers are also vulnerable and then point out how terrorists could use > these vulnerabilities against us. If you can, name some specific > organizations where you know the vulnerability exists. Pick a large > organization or two that has many nameservers and the vulnerability exists > in some obscure corner of the organization, not on their main nameservers. > They really can't sue over this because you haven't damaged them by > disclosing enough detail for an attacker to use. > > c. release to both the national press and the computer/network trade > press. > > That's how you get people's attention and that's also how the clueful > technical people get the authority and funding to go in and fix the > vulnerable boxes. As long as we continue to play games and pretend that > Internet operations is still the old boys club that it once was, we will > continue to suffer from these nagging issues. > > People on the NANOG mailing list do not run the Internet anymore. NANOG's > market share of network operations people has been steadily shrinking as > the Internet has grown. This may still be the moist clueful gathering > place, but there are an awful lot of people out there today designing, > building and operating networks, who have never heard of NANOG. > > There is no universal forum anymore. The Internet isn't special anymore. > > --Michael Dillon
RE: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003, E.B. Dreger wrote: > CK> The way I see it, the issue isn't that there aren't enough > CK> notifications of BIND vulnerabilities. > > Perhaps. But how much is enough? Current notification levels > certainly get a fair number of admins to upgrade. The majority of those who don't keep up with security releases won't unless their systems break or you personally notify them and explain the problem to them...much like equipment with unmaintained bogon filters go unfixed until you track down the responsible parties and thwap them on the head. Short of designing some kind of time bomb (make it possible to turn it off in the config for those who simply can't upgrade and don't intend to) such that after a certain age or other trigger, the code simply refuses to run, the unmaintained systems simply aren't going to get upgraded How hard would it be to have bind do some sort of secure.bind.isc.org query at start-up or perhaps even periodically and have it log lots of warnings or refuse to run if the query comes back and tells it the local version has been deferred due to security updates? One obvious problem with this would be that certain vendors prefer to backport security fixes to older versions rather than test and release new versions...so an insecure-looking version string may actually have had fixes applied. Perhaps the query could be for a timestamp that's defined in the source with the assumption that any code older than the most recent security update must be insecure. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: how to get people to upgrade? (Re: The weak link? DNS)
CK> Date: Wed, 26 Mar 2003 11:59:02 -0500 CK> From: "Kuhtz, Christian" CK> The way I see it, the issue isn't that there aren't enough CK> notifications of BIND vulnerabilities. Perhaps. But how much is enough? Current notification levels certainly get a fair number of admins to upgrade. CK> Administrator inertia is the root cause. I don't see how an CK> automatism such as the one described changes human behavior. CK> And unless you change that inertia, no amount of CK> notification, databases, registries, yada yada yada will make CK> any difference. Correct. Human behavior won't change. The pain must exceed the inertia. Sounds familiar. Have we seen this before? Outdated bogon filters... old software... spam... needless route deaggregation... broken smurf filters... ingress/egress filtering... Anything relying on widespread human responsibility is foredoomed to failure. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: how to get people to upgrade? (Re: The weak link? DNS)
Perhaps nameservers could periodically poll dig @?.root-servers.net 2.2.9.is-vuln.bind. txt chaos or something similar; I suggest using roots because DNS queries to them are far less likely to be filtered. If corresponding RR is valid (see below), shut down BIND, thus forcing admins to look into the problem. Harsh? Yes. Sadly, "it runs, so it must be correct" is far more common an attitude than "it must be correct before it's allowed to run". Worried about spoofing? Distribute the public key with BIND, and let the TXT response be encoded. Of course, the clueless generally don't compile from source. I wonder how long it would be before some vendor circumvented such controls so their userbase wouldn't be hassled with such silliness as forced critical upgrades. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: how to get people to upgrade? (Re: The weak link? DNS)
> On 26 Mar 2003, Jeffrey C. Ollie wrote: > > What I would like to see is somewhat of the idea in > > reverse. The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I really like this solution. It seems clean and unobjectionable, while > getting the job done. What's the job, though? The way I see it, the issue isn't that there aren't enough notifications of BIND vulnerabilities. Administrator inertia is the root cause. I don't see how an automatism such as the one described changes human behavior. And unless you change that inertia, no amount of notification, databases, registries, yada yada yada will make any difference. Thanks, Christian * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
Re: [Re: how to get people to upgrade? (Re: The weak link? DNS)]
"Jeffrey C. Ollie" <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2003-03-26 at 09:24, Paul Vixie wrote:
> > so here's a proposal. we (speaking for ISC here) could add a config
> > option
> > (default to OFF) to make bind send some kind of registration packet
> > at boot
> > time, containing an e-mail address for a technical contact for that
> > server,
> > and perhaps its hostname as well.
> >
options {
...
...
// this option is here to remind you when it is time to be a
// responsible netizen - choices are on or off, default is on
fetch-clue on
...
}
> > [...]
> >
> > given such a feature, whose default was OFF, would anyone here who
> > uses
> > BIND stop using it out of protest? if so plz answer publically (on
> > nanog).
>
> I would not use such a feature, and I suspect that most people who would
> use such a feature would not have a clue that it was there or how to
> turn it on. What I would like to see is somewhat of the idea in
> reverse. The ISC would host a zone that would contain TXT records with
> security/bug advisories for every version:
>
> $ORIGIN .
>
> security-notice.bind IN SOA ns.isc.org. postmaster.isc.org. 1
> 72003600
604800 3600
>
> $ORIGIN security-notice.bind.
>
> 8.3.3 IN TXT "Name: BIND: Multiple Denial of Service [yadda
> yadda
yadda...]"
> 4.9.10IN TXT "Name: LIBRESOLV: buffer overrun
> [yadda yadda yadda...]"
>
> yadda yadda yadda...
>
> Ideally the zone would be DNSSEC signed as well.
>
don't foget to include some useful/helpful comments regarding where to
look for more info
> Then, by default, BIND would query the zone periodically (perhaps every
> 24 hours or so) for it's version. If any records are found it would log
> a message and/or send email to [EMAIL PROTECTED], which would be repeated
> periodically (I'd log a message every time that a check was performed,
> but I'd only email once a week). There would be config options so that
> the clueful admin could customize/disable this behavior to his or her
> liking.
i like this idea better, and every little bit helps, but i still have
some reservations:
for the install-and-forget crowd (it is runnning right - well then why
would i want to mess with it), i don't know that they would see the
periodic messages, know how to act on them (although i am sure that very
detailed instructions could be included in each email), or care to act on
them. unless there is a blinking icon in the 'taskbar' that they click
on, and then magically when the machine has rebooted, they are up2date
with everything, i have doubts that it would work for a lot of the
servers out there (besides, how will any of this prompt those whom are
currently out of date to upgrade?)
>
> This way no one would be collecting a central database of email
> addresses, but everyone would get notified of security advisories in a
> timely manner.
>
> Jeff
>
>
my $0.02
joshua
"Walk with me through the Universe,
And along the way see how all of us are Connected.
Feast the eyes of your Soul,
On the Love that abounds.
In all places at once, seemingly endless,
Like your own existence."
- Stephen Hawking -
Re: how to get people to upgrade? (Re: The weak link? DNS)
> The ISC would host a zone that would contain TXT records with > security/bug advisories for every version: I have a better idea. ISC could set up a web page that would contain security/bug advisories for every version. In order to make it easier for people to find this web page, it could be listed in various directories such as CERT. And it could also be put into search engines so that someone could go to Google, type in "BIND bug site:isc.org" and click "I'm Feeling Lucky". > yadda yadda yadda... Indeed! Let's face it folks, DNS is not the tool of choice for publishing anything other than the mapping between hostnames and IP addresses. For some things the web is better. For others LDAP is better. And for the problem that Paul mentioned at the beginning there is only one solution; the press. The fact is that Paul wants to catch the attention of people who aren't paying attention right now. He has stated that email notices don't work and we can assume that the BIND security web page, and CERT's web pages also don't work. No, there is only one thing Paul can do right now. a. Collect some realistic numbers as to the number of DNS servers that are vulnerable to the various exploits. Ask people who do network scanning to provide some statistics on what they see and scale them up according to the number of hosts in the host-count database. For example, assume that someone has scanned N hosts and discovers that N/10 are running BIND and that 40% of those are vulnerable. Also assume that the hostcount shows 20 million hosts in the world. Infer from this that there are 2 million BIND servers and that there are 800,000 vulnerable ones. But do the calculations with some real data, not my example figures. b. Write a press release with the following headline: N Thousand Internet Servers Suffer Same Fate as Iraqi Server Or maybe write some variation on this but keep it scary and keep Iraq in the headline. The body of the press release should explain the attacks that the Iraqi server was suffering from, then point out how many other servers are also vulnerable and then point out how terrorists could use these vulnerabilities against us. If you can, name some specific organizations where you know the vulnerability exists. Pick a large organization or two that has many nameservers and the vulnerability exists in some obscure corner of the organization, not on their main nameservers. They really can't sue over this because you haven't damaged them by disclosing enough detail for an attacker to use. c. release to both the national press and the computer/network trade press. That's how you get people's attention and that's also how the clueful technical people get the authority and funding to go in and fix the vulnerable boxes. As long as we continue to play games and pretend that Internet operations is still the old boys club that it once was, we will continue to suffer from these nagging issues. People on the NANOG mailing list do not run the Internet anymore. NANOG's market share of network operations people has been steadily shrinking as the Internet has grown. This may still be the moist clueful gathering place, but there are an awful lot of people out there today designing, building and operating networks, who have never heard of NANOG. There is no universal forum anymore. The Internet isn't special anymore. --Michael Dillon
Re: how to get people to upgrade? (Re: The weak link? DNS)
* [EMAIL PROTECTED] (Paul Vixie) [Wed 26 Mar 2003, 16:24 CET]: > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). So how much would this differ from `make install' running this shell script? --- cat
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 08:31:40 -0800, Bill Woodcock said: > > On 26 Mar 2003, Jeffrey C. Ollie wrote: > > What I would like to see is somewhat of the idea in > > reverse. The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I really like this solution. It seems clean and unobjectionable, while > getting the job done. Plus, it is expandable to other common services that might want this service, like sendmail or OpenSSH.
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 26 Mar 2003, Jeffrey C. Ollie wrote: > What I would like to see is somewhat of the idea in > reverse. The ISC would host a zone that would contain TXT records with > security/bug advisories for every version: I really like this solution. It seems clean and unobjectionable, while getting the job done. -Bill
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 2003-03-26 at 09:24, Paul Vixie wrote: > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. > > [...] > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). I would not use such a feature, and I suspect that most people who would use such a feature would not have a clue that it was there or how to turn it on. What I would like to see is somewhat of the idea in reverse. The ISC would host a zone that would contain TXT records with security/bug advisories for every version: $ORIGIN . security-notice.bindIN SOA ns.isc.org. postmaster.isc.org. 1 72003600604800 3600 $ORIGIN security-notice.bind. 8.3.3 IN TXT "Name: BIND: Multiple Denial of Service [yadda yadda yadda...]" 4.9.10 IN TXT "Name: LIBRESOLV: buffer overrun [yadda yadda yadda...]" yadda yadda yadda... Ideally the zone would be DNSSEC signed as well. Then, by default, BIND would query the zone periodically (perhaps every 24 hours or so) for it's version. If any records are found it would log a message and/or send email to [EMAIL PROTECTED], which would be repeated periodically (I'd log a message every time that a check was performed, but I'd only email once a week). There would be config options so that the clueful admin could customize/disable this behavior to his or her liking. This way no one would be collecting a central database of email addresses, but everyone would get notified of security advisories in a timely manner. Jeff
Re: how to get people to upgrade? (Re: The weak link? DNS)
Thinking about it again, this would have additional advantage of collecting statistics at where bind is being used (you get ips of the servers) and what versions they are running. So even if they did not update the software, you can still find out where they are by ip address and if situation is very very serious, some kind of proactive contact option would still be available. On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > Personaly I'v not looked favorably at given my email to various lists, > although its probably way too late and everyone by now has it... > > 1. I have another idea though, during setup of the server ask for email > address of list administrator, but keep that on the server itself. > 2. Setup some dns server that provides dns record if there are necessary > updates (here is one example in reverse dns notation...: > 1.2.9.bind.updates.isc.org and set it to particular ip or > particular MX or whatever to show if update is needed). > Possibly have this special update dns recorb be HINFO to url where more > information on update is available. > 3. When bind starts if the record in #2 exists and shows that update is > necessary, have bind server email to address entered in 1 and with > abscense of that have it email to [EMAIL PROTECTED] and if HINFO > exists, it can take that and enter this as custome email. > > The above also makes it unnecessary for ISC to maintain that huge email > database or email everybody (and probably get bunch of people angry at you > for spamming...). Anyway just a thought... > > On 26 Mar 2003, Paul Vixie wrote: > > > > > [EMAIL PROTECTED] (Sean Donelan) writes: > > > > > What even stranger about the Iraqi state provider Uruklink.net is the DNS > > > servers are now self-identifying with earlier (with known bugs) versions > > > of BIND. Last week the Uruklink name server 62.145.94.1 was running > > > 8.2.2-P5, but now is running 8.1.2. ... > > > > at http://www.isc.org/products/BIND/bind-security.html we see: > > > > Name: "BIND: Remote Execution of Code" > > [Added 11.12.2002] > > Versions affected: BIND 4.9.5 to 4.9.10 > > BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 > > Severity: SERIOUS > > Exploitable: Remotely > > Type: Possibility to execute arbitrary code. > > Description: > > > > When constructing a response containing SIG records a incorrect > > space allows a write buffer overflow. It is then possible to > > execute code with the privileges of named. > > > > the list goes on. i'm sure several folks will use this as an opportunity to > > hawk their own alternative non-BIND DNS solution, i wish you well except plz > > change the Subject: header on your reply since what i really want to talk > > about is: how to get people to upgrade their software when defects are found. > > > > sending out announcements through CERT and the bind-announce m/l isn't working. > > > > so here's a proposal. we (speaking for ISC here) could add a config option > > (default to OFF) to make bind send some kind of registration packet at boot > > time, containing an e-mail address for a technical contact for that server, > > and perhaps its hostname as well. the destination would be configurable, and > > the format would be open, and we would include in the distribution a tool > > capable of catching these. any campus/WAN admin who wanted to run their own > > "BIND registration system" could do so. anyone who wanted to simply config > > their server to send registration data to ISC could do so. for data received > > at ISC, we'd (a) keep it completely private other than public statistics, > > (b) clean it of obvious trash (some people will sent registration data for > > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > > information only in the event that a security defect discovered in that > > version. remember, the default would be OFF. > > > > given such a feature, whose default was OFF, would anyone here who uses > > BIND stop using it out of protest? if so plz answer publically (on nanog). > > > > given such a feature, would anyone here create their own registration system > > so they had their own database of local BIND instances on their campus/WAN, > > or would anyone here config their servers to send registration data to ISC? > > if so plz answer privately (i'll summarize to the list.) >
Re: how to get people to upgrade? (Re: The weak link? DNS)
Personaly I'v not looked favorably at given my email to various lists, although its probably way too late and everyone by now has it... 1. I have another idea though, during setup of the server ask for email address of list administrator, but keep that on the server itself. 2. Setup some dns server that provides dns record if there are necessary updates (here is one example in reverse dns notation...: 1.2.9.bind.updates.isc.org and set it to particular ip or particular MX or whatever to show if update is needed). Possibly have this special update dns recorb be HINFO to url where more information on update is available. 3. When bind starts if the record in #2 exists and shows that update is necessary, have bind server email to address entered in 1 and with abscense of that have it email to [EMAIL PROTECTED] and if HINFO exists, it can take that and enter this as custome email. The above also makes it unnecessary for ISC to maintain that huge email database or email everybody (and probably get bunch of people angry at you for spamming...). Anyway just a thought... On 26 Mar 2003, Paul Vixie wrote: > > [EMAIL PROTECTED] (Sean Donelan) writes: > > > What even stranger about the Iraqi state provider Uruklink.net is the DNS > > servers are now self-identifying with earlier (with known bugs) versions > > of BIND. Last week the Uruklink name server 62.145.94.1 was running > > 8.2.2-P5, but now is running 8.1.2. ... > > at http://www.isc.org/products/BIND/bind-security.html we see: > > Name: "BIND: Remote Execution of Code" > [Added 11.12.2002] > Versions affected: BIND 4.9.5 to 4.9.10 > BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 > Severity: SERIOUS > Exploitable: Remotely > Type: Possibility to execute arbitrary code. > Description: > > When constructing a response containing SIG records a incorrect > space allows a write buffer overflow. It is then possible to > execute code with the privileges of named. > > the list goes on. i'm sure several folks will use this as an opportunity to > hawk their own alternative non-BIND DNS solution, i wish you well except plz > change the Subject: header on your reply since what i really want to talk > about is: how to get people to upgrade their software when defects are found. > > sending out announcements through CERT and the bind-announce m/l isn't working. > > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). > > given such a feature, would anyone here create their own registration system > so they had their own database of local BIND instances on their campus/WAN, > or would anyone here config their servers to send registration data to ISC? > if so plz answer privately (i'll summarize to the list.)
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 15:24:18 +, Paul Vixie said: [snip] > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. I'm not sure this helps. The people who don't subscribe or pay attention to CERT advisories are the same ones that won't turn this option on. It is like the cache option in Apache; the people who would get the most benefit, the ones with mainly static web pages, are the same ones who do not know to turn it on. -Dave
how to get people to upgrade? (Re: The weak link? DNS)
[EMAIL PROTECTED] (Sean Donelan) writes: > What even stranger about the Iraqi state provider Uruklink.net is the DNS > servers are now self-identifying with earlier (with known bugs) versions > of BIND. Last week the Uruklink name server 62.145.94.1 was running > 8.2.2-P5, but now is running 8.1.2. ... at http://www.isc.org/products/BIND/bind-security.html we see: Name: "BIND: Remote Execution of Code" [Added 11.12.2002] Versions affected: BIND 4.9.5 to 4.9.10 BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 Severity: SERIOUS Exploitable: Remotely Type: Possibility to execute arbitrary code. Description: When constructing a response containing SIG records a incorrect space allows a write buffer overflow. It is then possible to execute code with the privileges of named. the list goes on. i'm sure several folks will use this as an opportunity to hawk their own alternative non-BIND DNS solution, i wish you well except plz change the Subject: header on your reply since what i really want to talk about is: how to get people to upgrade their software when defects are found. sending out announcements through CERT and the bind-announce m/l isn't working. so here's a proposal. we (speaking for ISC here) could add a config option (default to OFF) to make bind send some kind of registration packet at boot time, containing an e-mail address for a technical contact for that server, and perhaps its hostname as well. the destination would be configurable, and the format would be open, and we would include in the distribution a tool capable of catching these. any campus/WAN admin who wanted to run their own "BIND registration system" could do so. anyone who wanted to simply config their server to send registration data to ISC could do so. for data received at ISC, we'd (a) keep it completely private other than public statistics, (b) clean it of obvious trash (some people will sent registration data for [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact information only in the event that a security defect discovered in that version. remember, the default would be OFF. given such a feature, whose default was OFF, would anyone here who uses BIND stop using it out of protest? if so plz answer publically (on nanog). given such a feature, would anyone here create their own registration system so they had their own database of local BIND instances on their campus/WAN, or would anyone here config their servers to send registration data to ISC? if so plz answer privately (i'll summarize to the list.) -- Paul Vixie
