This document contains information about robustness of this project against hacker attacks. It describes known vulnerabilities that have been found in previous versions, and describes policies how vulnerabilities are handled.
[email protected] @ErrataRob on twitter
none
I'm offering $100, payable in cash or Bitcoin, for security vulnerabilities. This is primarily for remote vulnerabilities, such as the ability of a target to buffer-overflow the scanner, or even cause it to crash.
But I'd consider other vulnerabilities as well. Does Kali ship this with suid and there's a preload bug? That's not really a vuln in this code, but if it's something I could fix, I'd consider paying a bounty for it.
If you've got a vuln, just announce it. Please send info to the contact above as well, please.
I'll probably get around to fixing it within a month or so. This really isn't heavily used software, so I'm lax on this.
The primary threat is from hostile targets on the Internet sending back responses in order to:
- exploit a buffer-overflow vulnerability
- spoof packets trying to give fraudulent scan results (mitigated with our SYN cookies)
- flood packets trying to overload bandwidth/storage
- bad data, such as corrupting banners or DNS names trying to exploit downstream consumers with bad or <script> tags.
The secondary threat is from use of the program. For example, when a bad
parameter is entered on the command-line, the program spits it back out
in a helpful error message. This is fine for a command-line program that
should run as root anyway, but if somebody tries to make it into a
scriptable service, this becomes a potential vulnerability.
Unsafe functions like strcpy() are banned.
The code contains an automated regression test by running with the
--regress option. However, currently the regression only tests
a small percentage of the code.