Security-related bugs

[Duncan Findlay <du...@debian.org>]

I was hoping to start a discussion over what constitutes a "security"
bug in our Bugzlla. This is not meant to criticize any previous
decisions around security, merely to gauge how we feel about this as a
community.

So, here I'd like to outline the criteria I would suggest for
determining whether a bug should be classified as "security" and
restricted to the "security team." Please comment. :-)

 - Bugs which allow false negatives are not security bugs. In
particular if a bug allows a carefully crafted message to bypass some,
but not all, of SpamAssassin's tests, then it should not be marked as
"security".

 - DOS attacks and other related, *exploitable* bugs that cause
disruption to mail-scanning or other problems for the server are
security bugs. (I don't consider 4570 to be a security bug, for
example. It's just not exploitable by spammers.)

 - Bugs that allow a specially crafted spammy message to get through
regardless of any other charactersistics (i.e. header, body, Bayes and
other tests fail to count) may be security bugs. (I'd argue it's not
strictly speaking a security issue for the system, but it is something
we should maybe not make public. I could be convinced either way on
this.)


Lastly, I'd like to say that once a bug is outlined in the open, there
is no point to hide it after the fact. In fact, all this may
accomplish is to hide the fix from our users, even though a
description of the "exploit" is publicly available. (Example: bug
4759, 4535, others I'm sure.)

-- 
Duncan Findlay

Re: Security-related bugs

[Loren Wilton <lw...@earthlink.net>]

> IMO, bugs which allow any specially crafted spammy message to get
> through, even if the method used is to crash spamd or stand-alone SA,
> is NOT a security bug, provided the only damage is to SA/spamd and the
> resulting FN. That's a bug, pure and simple, no matter how creative
> the spammer is.

As an outside opinion I think I'd differ slightly here.

If the message is capable of crashing or locking up part of the SA chain, so
that the result is either no mail gets through or all subsequent mail gets
through unscanned, then I'd classify it as a private bug for discussion
purposes, and I'd also give it a number 1A1 priority rating for getting a
patch out for the affected versions.

I think I might do this even after a public *detailed, with example* report
of the method, but that is debatable.  I would certianly be inclined to
classify the example until a fix was available.

OTOH, if the message simply results in an FN for whatever reason, but
doesn't affect subsequent processing or server load unacceptably, then it is
NOT a security bug.

        Loren

Re: Security-related bugs

[Robert Menschel <Ro...@Menschel.net>]

Hello Duncan,

Tuesday, January 10, 2006, 4:52:41 PM, you wrote:

DF> So, here I'd like to outline the criteria I would suggest for
DF> determining whether a bug should be classified as "security" and
DF> restricted to the "security team." Please comment. :-)

Good.

DF>  - Bugs which allow false negatives are not security bugs. In
DF> particular if a bug allows a carefully crafted message to bypass some,
DF> but not all, of SpamAssassin's tests, then it should not be marked as
DF> "security".

I'd go further,

DF>  - Bugs that allow a specially crafted spammy message to get through
DF> regardless of any other charactersistics (i.e. header, body, Bayes and
DF> other tests fail to count) may be security bugs. (I'd argue it's not
DF> strictly speaking a security issue for the system, but it is something
DF> we should maybe not make public. I could be convinced either way on
DF> this.)

IMO, bugs which allow any specially crafted spammy message to get
through, even if the method used is to crash spamd or stand-alone SA,
is NOT a security bug, provided the only damage is to SA/spamd and the
resulting FN. That's a bug, pure and simple, no matter how creative
the spammer is.

DF>  - DOS attacks and other related, *exploitable* bugs that cause
DF> disruption to mail-scanning or other problems for the server are
DF> security bugs. (I don't consider 4570 to be a security bug, for
DF> example. It's just not exploitable by spammers.)

Fully agreed.  If any message (intentionally crafted or not) can cause
impact on any system other than SA, and any effect other than FNs,
then it's a security bug.

DF> Lastly, I'd like to say that once a bug is outlined in the open, there
DF> is no point to hide it after the fact. In fact, all this may
DF> accomplish is to hide the fix from our users, even though a
DF> description of the "exploit" is publicly available. (Example: bug
DF> 4759, 4535, others I'm sure.)

Given three phases:  discovery and report, discussion, and fix, I'd
suggest it's useful to secure the discussion, to prevent additional
information on how to exploit the security bug from being published.
Once a fix or work-around has been developed for a revealed security
bug, then yes, that fix or work-around should be revealed similarly.

Bob Menschel