Nmap security audit

[Solar Designer <solar () openwall com>]

Hi,

One of the TODO items for Nmap, which will likely stay there forever
(for two reasons), is a proactive security audit of the source code.

I think that we also need a TODO for the audit (things to check, risks
to consider).  I am assuming that one does not exist yet, so here's a
start (my raw notes):

liblua string processing

liblua integer overflows when calculating memory allocation sizes

printing of untrusted input to programs' output (risk of terminal escapes)
        for input obtained from the remote by ...
                nmap itself
                NSE scripts
                ncat
        ncat --chat

Feel free to comment on this and/or add to it.

The audit, if performed, will also force us to define the correct
behavior, which is currently largely undefined.  For example, is it
Nmap suite programs' job to ensure they don't print untrusted input
directly to their output?  Perhaps usually it is, and those cases will
need to be identified (or rather, cases when it is appropriate to print
the data verbatim, such as by ncat in most of its modes).

Unfortunately, I do not expect to have much time for this myself, so
this posting is mostly to hopefully get others started at this task. ;-)
We'll see it it works or not.

Alexander

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