Optimize NFR.Part 1-MSSQL Hello Buffer Overflow

[Matt LeGrow <mlegrow () nfr com>]

As members of NFR's Rapid Response Team, and the principal authors of the
signatures for our IDS product, we would like to reply to benjurry's post
on the XFocus.org web site regarding optimization of NFR's MSSQL
signature.  Although this article provides some helpful pointers on why
this signature can produce false positives, it also crosses frequently
into the realm of subjective opinion and distorts facts while trying to
maintain the guise of objective analysis.  We'd like to address a few of
the more troubling omissions in benjurry's article below:

1) The original N-code signature that benjurry included with the article
is copyrighted code and was posted without permission from NFR Security.

2) MSSQL is in the class of signatures known as "Rapid Responses".  Its
important to note that a quick sig written to detect an MSSQL exploit is
*far* different from a mature package.  RRs are released typically in
conjunction with major holes or vulnerabilities.  As customers depend on
us delivering them with expediency, both manpower and time issues are at
stake.  They have different release cycles, maintenance priority, and yes,
standards, than a major package (like WWW, SSH, SMTP, FTP, etc) to most
efficiently deliver coverage to our customer base.  In this respect, they
are roughly analogous to Snort's "snort-current" ruleset.  Most Rapid
Responses eventually end up getting absorbed into larger packages, while
some (like MSSQL) persist because there is no major package yet to house
them.

3) The basic premise of this article is that the signature is ineffective.
It goes unmentioned in the paper that NFR customers armed with this same
Rapid Response were among the very first to detect the Slammer outbreak.

Far more dubious is the implication benjurry makes when he criticizes
our Rapid Response (and our signature set in general) and then
pontificates on why third-party analysts still praise our product. He
states that "in order to reduce the cost ,many manufacturer of IDS
don't research the vulnerability and system, but collect the exploits.
That is why there are many False Positives in IDS and why they do well in
many evaluations."  Such a statement ignores the fact that the signature
baseline tests are only a small part of what those evaluators do.  In the
case of OSEC, for example, i'd like to remind folks of the testing
criteria at

http://osec.neohapsis.com/criteria/nids-v1/testsummary.html

A quick glance at the overall tests (in particular the Discard Tests) as
well as the individual test results will show that the OSEC folks not only
created a framework where false positives would inhibit an IDS from
performing well, but also reported false positives where and when they
occurred.

We're not interested in killing anyone's opinions of our product, nor do
we mind customers sharing their modifications to our N-Code (as long as
they are mindful of protecting our intellectual content).  But analysis
loses its effectiveness when it is merely a veil for personal opinion.


NFR Rapid Response Team
http://www.nfr.com/rrt



---------------------------------------------------------------------------
Attend Black Hat Briefings & Training Federal, September 29-30 (Training), October 1-2 (Briefings) in Tysons Corner, 
VA; the world’s premier 
technical IT security event.  Modeled after the famous Black Hat event in 
Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.  
Symanetc is the Diamond sponsor.  Early-bird registration ends September 6 Visit: www.blackhat.com
---------------------------------------------------------------------------