Re: [NSE] Release of nmap nse vulscan 0.6

[Fyodor <fyodor () insecure org>]

On Thu, Jun 03, 2010 at 09:21:58AM +0200, Marc Ruef wrote:
> Hello,
>
> As I have announced in my post to the nmap-dev mailing list in mid-May, 
> I wrote another nse script[1]. This script adds the functionality of a 
> basic (derivative) vulnerability scanner. The first public release can 
> be downloaded at my personal web site at:
>
>    http://www.computec.ch/mruef/?s=software&l=x

Hi Marc.  This is exciting stuff, and I do think Nmap should include a
script with this functionality!  I mean, in the ideal world, we would
have checks for each important vulnerability which check in a more
reliable way than simple OS, service, and version number comparison.
But we're not going to have such a comprehensive selection of checks
any time soon, so there is a ton of value in a simple DB which just
flags based on OS, service, application, and app version information.

We'd probably want disclaimers in cases where the results are
reasonably likely to be off.  For example, if we don't know the app
version number, it might make sense to still print the possible vuln,
but note that it could already be patched in this version.  We'd want
a similar disclaimer in cases where the app is commonly patched in
place, without changing the version number.  We'd probably want to do
the warning by default, and suppress it where signatures are marked as
reliable.

Using OSVDB data is a clever idea, but it does have a couple concerns.
One is the license (http://osvdb.org/license).  It imposes a number of
significant conditions.  For example, I don't know if your patch
displays the OSVDB credit information during program execution.  The
license conditions are reasonable and not to onerous, but still could
be problematic.  For example, anyone who makes derivative works of
Nmap needs to know that they need to follow the OSVDB license as well.
Still, we might be able to deal with that aspect or negotiate
something with the OSVDB folks.  It would just take a bit of figuring
out.  But there is the bigger problem...

As you note, the OSVDB information is not canonicalize to match
Nmap's version/OS detection strings.  So using OSVDB would presumably
take a lot of work to modify one or the other.  And many OSVDB entries
I've just browsed don't seem to have the vulnerable version numbers of
the affected application.  We could do a rather brute-force text
search like you're doing, but that seems to lead to many false
positives.

I haven't spent a lot of time examining the OSVDB data, so it may be
the best approach.  But my initial thought is that it would be better
for Nmap to have its own DB with simple signatures based on Nmap's
service/application names, version numbers, and OS names.  Of course,
during research, you could use factual data from OSVDB, CVE, and other
sources to create signatures.  Also, the signatures would presumably
include vuln reference numbers from OSVDB and CVE and/or a link to the
original advisory on seclists or wherever, and/or a link to an NSE
script for detecting or exploiting the vuln.

My feeling is that if we could find a vuln DB which really has what we
need, and then we can figure out the licensing to get it included in
Nmap, that would be ideal.  So it is worth checking for that first.
But assuming that can't be found, I think the best idea is to do our
own system with signatures designed just for Nmap's needs.  That will
make it a much smaller and easier project than OSVDB as a whole.  I
think if we started with a decent DB (even just 100 or 200 key
vulnerabilities), we could get community contributions to help
maintain it.  They key is that it has to start out in a useful enough
state to have critical mass to get people to start submitting new vuln
sigs.  If it becomes popular enough, we could even create an online
process for doing that as part of http://nmap.org/submit/.

Anyway, thanks for starting this exciting project and I hope Nmap
proper will have this functionality someday.

Cheers,
Fyodor
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/