Complete.Org: Mailing Lists: Archives: linux-help: October 2003:
[linux-help] Re: security list
Home

[linux-help] Re: security list

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: linux-help@xxxxxxxxx
Subject: [linux-help] Re: security list
From: John Goerzen <jgoerzen@xxxxxxxxxxxx>
Date: Thu, 2 Oct 2003 14:04:25 -0500
Reply-to: linux-help@xxxxxxxxx

On Thu, Oct 02, 2003 at 01:32:23PM -0500, M. Osten wrote:
> > Sometimes I want a moderated and censored list.  If you want to find out
> > about patches for software you run and some security headlines, it's a good
> > place to be.
> Hum, what about when your vendor doesn't release a patch for an extended
> period?  Don't you want to know if there is an exploit in the wild so

Then either they a) look stupid because you see that there are patches
available elsewhere, or b) are a single source of a binary program that
you're helpless to fix anyway.

> you can take some sort of action?  Or even better yet, how about when a
> vendor puts pressure on Bugtraq to not post an advisory when there is
> exploits in the wild?

I'm not aware of any popular Linux vendors that do that, and I say that as
someone that has been involved with security coordination among Linux
vendors.

> You could get what your wanting on slashdot.

No, Slashdot only covers popular or interesting security problems.

> > I've found that full disclosure has such a low signal-to-noise ratio that
> > it's nearly useless.  I don't care about exploit code except perhaps to
> > verify that a fix has worked, so that's no extra benefit for me.
> 
> Hence Full Disclosure=no censorship, you have to take the good with the
> bad.  I agree that the amount of noise is great, but how else is there
> to be reactive about security? (Waiting for the vendor to release the
> advisory/patch shouldn't be an option for anyone).

Blanket statements such as that are trivially disproved.

For instance, when the ssh vulnerabilities were first announced, I
immediately compiled new versions for some prominent publically-visible
servers.  However, for workstations that are on an internal network behind
two firewalls, I decided that it made no sense to rush to get a
haphazardly-compiled version installed and instead waited a couple of hours
for the new Debian packages.  Setting up a proper build environment,
building, and testing for all those different environments would have
probably taken longer than waiting for the official fix.

And you're even arguing a worse case -- saying that I shouldn't even bother
to wait until the SSH team releases their advisory and patch.  While
sometimes people on the 'net can make good patches, I found that often there
are incomplete or incorrect "fixes" floating around that can be worse than
doing nothing at all.



-- This is the linux-help@xxxxxxxxx list.  To unsubscribe,
visit http://www.complete.org/cgi-bin/listargate-aclug.cgi


[Prev in Thread] Current Thread [Next in Thread]