RE: how to get people to upgrade? (Re: The weak link? DNS)

    > 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

Date: Wed, 26 Mar 2003 11:59:02 -0500
From: "Kuhtz, Christian"

The way I see it, the issue isn't that there aren't enough
notifications of BIND vulnerabilities.

Perhaps. But how much is enough? Current notification levels
certainly get a fair number of admins to upgrade.

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.

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

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.

: 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...

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

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.

:wink: scott

Date: Wed, 26 Mar 2003 13:00:57 -0500 (EST)
From: Jon Lewis

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

Not hard. Again, I'm in favor of refusing to run... I've
encountered waaay too many "I click <OK> and it works" people.

with this would be that certain vendors prefer to backport security fixes
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.

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.

This would make a good second/additional/whatever check.

Eddy

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

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

Charles Sprickman 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).