Re: thoughts on kernel security issues

[jtjm@xenoclast.org (Julian T. J. Midgley)]

In article <871xcoxduk.fsf@deneb.enyo.de>,
Florian Weimer  <fw@deneb.enyo.de> wrote:
>* Julian T. J. Midgley:
>
>>>vendor suffer from that as well. Suppose vendors learn of a problem in
>>>a product they visibly use such as apache or rsync. If all vendors
>>>suddenly update their versions or disable things that will be noticed as
>>>well, so vendors can't do that.
>>
>> I don't buy that at all.  There are numerous reasons for updating
>> programs or disabling things, of which fixing security holes is but
>> one.
>
>People used to monitor large name servers run by the in-crowd for
>synchronous updates, to get advance notice of the existence of BIND
>security holes.  AFAIK, it was a reliable indicator.

It might well have been - did these people then trawl through the BIND
sources to try to find the bug itself, and frequently develop an
exploit before the official patches were released?  If so, why didn't
they just assume that there was a bug in BIND and go looking for it
instead of waiting for circumstantial evidence that there mighe be
before they started looking.  

You'll have to explain why leaking the information "that there is a
bug in $PROGRAM", by fixing it (without disclosing either the bug or
the fix), is a problem.  After all, you can assume that for every
black hat foolish enough to sit around waiting for some evidence that
a bug exists before trying to find it, there'll be another that just
went looking anyway and has already found it.  It's better for all
concerned that the vendors protect themselves against the latter bunch
as soon as they reasonably can.

Julian
-- 
Julian T. J. Midgley                       http://www.xenoclast.org/
Cambridge, England.
PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1  A7D5 3027 2F2E BCC7 863F