Re: [Emerging-Sigs] [Snort-devel] Snort 2.9.0.1 Now Available

[L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com>]

Hello.  Good points Mike.  One thing I want to make clear is that I
consider a bug that affects packet reassembly dependent detection as a
non-trivial security bug since it can lead to easier IDS/IPS evasion.
Specifically, this is the HTTP pre-processor issue I and others have
brought up and apparently affects 2.9.0.0, 2.8.6.1, and probably more
(I don't think I had the same problems with 2.8.5, though).  However,
SourceFire has chosen not to fix this bug in recent versions of snort
other than the latest minor release -- 2.9.0.1.  Be aware.

-L0rd C.

On Thu, Nov 4, 2010 at 11:50 AM, Mike Lococo <mikelococo () gmail com> wrote:
> On 11/03/2010 09:48 PM, Joel Esler wrote:
> > What versioning in Snort rules do you all find to be acceptable?
> >
> > Take into account that there is no way we can maintain every version
> > of every build and I am committing to nothing, I would just like to
> > hear some constructive ideas.
>
> I imagine my take is pretty clear by now, but for the record:
>
> * 2.9.latest and 2.8.latest is actually a good policy for rule
> availability (n.latest and n-1.latest for *major* versions).
> * Security-fix availability should be synced with rule-availability.
> Remote-exploits don't happen that often in snort, but SF should commit
> to releasing fixes for 2.8.latest until it's EOL'ed.  (ET-Pro may be
> releasing rules for 2.4, but will anyone fix vulnerabilities for it?)
> * Don't release disruptive new features, or features that break
> backwards compatibility within a major-series.  Wait for 2.10 or 3.0. We
> shouldn't have to worry about a ruleset for 2.9.1.0 causing 2.9.0.1 to
> fail on startup a month and a half after 2.9.0.1 was released.
> * Release new major-series on a semi-regular basis (once per year or
> once per 6-months), even if the changes in it aren't earth-shaking. This
> will get folks on a predictable upgrade schedule that they can plan for
> in advance.
>
> Support of any kind for 2.6 or earlier is a waste, IMO.  2.8 was
> released over three years ago, and anyone who hasn't been able to
> engineer an upgrade in that time period has problems that SF can't solve.
>
> Determining how to support different minor versions like 2.8.6 vs 2.8.5
> wouldn't be an issue if you adopted the versioning guidelines above
> since minor and patch releases within a major-series would be
> essentially interchangeable except for bug/security-fixes and
> optional-use new-features.  I imagine that you'd satisfy the 80/20 rule
> with a cutoff at 2.8.latest, but that going back to 2.8.5 would make
> some additional folks happy.
>
> Cheers,
> Mike Lococo
>
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs () emergingthreats net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs