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_________