Re: [RFC] Vulnerability library proposal

[Djalal Harouni <tixxdz () opendz org>]

On Sun, Aug 07, 2011 at 06:40:33PM +0200, Henri Doreau wrote:
> 2011/8/7 Djalal Harouni <tixxdz () opendz org>:
> > Hi list,
> >
> > This is a proposal for a new NSE vulnerability library. The library is
> > designed to help managing discovered vulnerabilities and to make the
> > output more consistent.
> >
> > It would be really great if we can have suggestions from pen-testers and
> > from people that integrate and use Nmap in their security tools.
> > Thanks in advance.
>
> Hi Djalal,
>
> thanks for the proposal, we've already discussed most of it together
> and I find it pretty cool but there's still one point I'd like to
> discuss.
Yes, and thanks for your help :)

> You propose a "all or nothing" approach to store vulnerabilities in
> the registry. Another option would be to let post-processing scripts
> register their own filters to the library in the prerule function.
> vulns.save_report() could take a callback in argument, just the same
> kind that the selection_filter which are described in the proposal.
> These filters would then be called each time a vulnerability is added
> by a script. If one of the callback filters returns true then the
> vulnerability is stored, otherwise we can discard it.
Yes I've already added them, but now I see that I wasn't clear enough.
function vulns.register_filter(callback_filter)

But perhaps using the vulns.save_reports() would be better ?
vulns.save_reports(script_name, callback_filter)

> That would prevent the lib from storing everything if the only
> post-processing script selected is one that just takes a small subset
> of the tested vulnerabilities (like "high risk vulnerabilities which
> are present"). We can also easily imagine some performance
> optimization, to do the filtering only once, when the vulnerability is
> added:
>   - post-proc. script registers a filter and gets an ID back from the library
>   - each time a vulnerability is added the filter is called against
> it, and if it returns true the vulnerability table is stored,
> associated to the ID of the filter.
>   - the post-proc. script iterates over all the vulnerabilities
> associated with its ID and report them or whatever...
I see, this is a nice idea and to implement it correctly we must call
all the filters, in other words do not _only_ associate and store the
vulnerability with the first ID filter that returns true.

We can have a situation when scripts register multiple filters, and
perhaps two or more of these filters will also return true if they process
the same vulnerability table, and if we return at the first filter that
returns true then we'll miss the others.

Perhaps we can create for each ID (SCRIPT_NAME) a namespace that will
only reference the selected vulnerabilities. In all cases we must make
the code more dynamic at runtime.


Thanks Henri.

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