Bug#564248: RM: snort/2.8.4.1-6
On Tue, 12 Jan 2010 00:11:15 +0100, Javier Fernández-Sanguino Peña
wrote:
> severity 553584 minor
> retitle CVE-2009-3641: Possible DoS using specially-crafted IPv6 packets if package is recompiled with IPv6 support
> thanks
>
>
> On Fri, Jan 08, 2010 at 08:42:21PM +0100, Raphael Hertzog wrote:
> > Hi,
> >
> > On Fri, 08 Jan 2010, Moritz Muehlenhoff wrote:
> > > Please remove snort from testing. It has an open security bug, which hasn't
> > > been acknowledged since more than two months.
> >
> > I'm a bit worried that we remove (popular) software from testing instead
> > of fixing the underlying problem.
>
> On review. The Snort packages provided by Debian are *not* vulnerable to this
> bug. We do not enable IPv6 support in Snort, as we don't compile with
> --enable-ipv6 (!)
>
> Did somebody from the Security Team actually read the full disclosure report
> [1] and test wether the vulnerability was actually there?
>
> I'm downgrading the severity of the bug and will fix it with the next
> upstream release.
>
> Security Team, please let me know if you consider this bug merits a DSA for
> stable and oldstable, (I don't think it does as they are not affected unless
> the package is recompiled.
It is often the case that the security team does not have the manpower
and time to fully triage issues when they come in since the volume is
just so high; so the issues are handed off to the maintainer (such as
in this case).
I have recently implemented new functionality in the security tracker
to better handle such partially triaged issues. However, that info is
not automatically conveyed by the current bug reporting utilities. It
is at present the responsibility of the reporter to explain to the
maintainer what has and has not been done, which was not done in this
case.
Perhaps in the future I will have some time to improve the automated
tools so that they include notes based on tracker status (since humans
have a tendency to make mistakes, which isn't a bad thing, its just a
fact of life). This would ensure that sufficient status information is
included in these reports.
Mike
Reply to: