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."
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 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
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 *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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 <OK> 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 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
Hi folks, Anybody seen/heard of major outages/jams in Florida today ? I'm having some pockets of resistance <smirk> making it impossible for me to get to Verisign, Sun, Reuters and AP from 65.87.x.x Appreciate any insights on or off list. thanks Bert
On Wed, 26 Mar 2003 jlewis@lewis.org 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 *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Charles Sprickman wrote:
On Wed, 26 Mar 2003 jlewis@lewis.org 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
: 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
participants (7)
-
Bruce Pinsky -
Charles Sprickman -
E.B. Dreger -
hostmaster -
jlewis＠lewis.org -
Kuhtz, Christian -
Scott Weeks