Re: [NSE] Check for CVE-2011-1720 - Postfix SMTP Cyrus SASL memory corruption

[Fyodor <fyodor () insecure org>]

On Thu, May 12, 2011 at 06:33:50PM +0100, Djalal Harouni wrote:
> Attached is just another clean version,

Thanks Djalal.  This is a nice script for an important vulnerability!
Regarding this line:

> categories = {"dos", "exploit", "intrusive", "vuln"}

The "intrusive" and "vuln" categories seem right on, but should this
script be in "dos" and "exploit"?  The question is whether the script
itself can be used to perform a DoS (intentionally or not) and whether
the script itself can be used to exploit the bug.  I don't think we
should use these categories if the reasoning is just that the
underlying vulnerability could be used to perform a DoS or exploit.
If the script can be used to perform a DoS or exploit, it should
probably be documented in the description.  Maybe these are just there
because you used smb-check-vulns as a template?  That one actually
does DoS services (if you use the right option) and does include an
exploit feature.

Also, I have mixed feelings about making this a smtp-check-vulns
script rather than being specific to the vulnerability it detects).
Do you already have other bugs you plan to add to this script?  Do
they benefit from being combined within this script rather than
separate?  I suppose you could probably reuse some of the code, but
that could be done by sharing an smtp library as well.

Admittedly your script follows the pattern of the well-loved
smb-check-vulns script.  But that one does at least check for multiple
vulnerabilities.  And, frankly, it might make more sense for that one
to be split up too.  It is a strange mix of checking for several
vulnerabilities, checking for the Conficker malware, exploiting a DoS
bug, and exploiting an SMBv2 vulnerability.

If you don't have more vulns in mind for this script, maybe it would
be best to name it after the Postfix Cyrus SASL vulnerability it
detects.  Then if we find a later SMTP vulnerability and we believe it
makes sense to combine detection into one script, we could do so then?
Or if we decide they would be best structured as different scripts
(from a user interface perspective), we could move the shared code to
a library.

Or maybe some folks think having a single vuln check script per
protocol might be a better model?

I do think that if we were doing local patch checks, it would probably
make more sense to have just one script for each platform which checks
if all the patches are installed than to do the Nessus/OpenVAS model
of one-script-per-issued-patch.

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