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
