Ron Gula: Source code of the Nessus daemon is not important to the majority of the Nessus user community. Source code of the vulnerability checks is very important and we're not changing that. Nessus has it's own language for vulnerability checks named NASL and this is something easily picked up by the average use, even non-coders.

We have not provided source code to anyone at this point.

Ron Gula: C

Ron Gula: First, it is not possible to run nessusd as an unprivileged user, because it needs the ability to launch local commands as root (for instance, one user could use Nessus to launch a Nmap port scan, and nmap needs to run as root). In the same vein, you can't chroot it as otherwise it would be unable to use any application on the local system.

Finally, you want nessusd to perform a complete audit and this involves forging and sniffing packets or opening sockets with a source port lower than 1024. These operations require root privileges. So we could try to come up with complex systems to try to avoid being "root" (by using the Linux 'capabilities' for instance), but one would inevitably end up either with a scanner which does not do its job at all, or with a process which can do everything 'root' can do but does not run as root.

Moreover, whether nessusd runs as root or not is irrelevant. If an attacker can execute arbitrary code in nessusd, he'd be better off sending the results of the network audit to his @gmail account rather than try to compromise the Nessus system itself.

That being said, most of the Nessus checks are written in NASL, which is a sandboxed language and which is resistant to common program mistakes such as buffer overflows, format string attacks or even null pointer de-referencement. Every protocol parser is implemented in NASL which greatly reduce the risk of seeing a programming mistake have adverse results.

Our research team has done an extensive job to determine what kind of attack could be done against the scanner and how to prevent them entirely, and not all of these attacks revolve around nessusd. For instance, one could very well install a fake SMB server on the network which claims to NOT support any encryption whatsoever and wait for a scanner to try to log in. Some scanners will send the administrative password in clear text, other won't. When you think about it, that's a clever attack because - as an attacker - you've not done anything illegal and obtained the domain administrative password. That's the kind of attack our research team thinks about and prevents.

In the end, we consider Nessus as being very robust and secure. Very few scanner vendors like to talk about the security measures they implement in their scanner but we do. Renaud even did a public talk about every possible attack which can be done and how they've been fixed a few months ago at JSSI, in France.

Ron Gula: It's the same approach in Nessus 3. Nessus 2 and Nessus 3 are more or less the same in this area, i.e. Nessus 3 isn't more secure than Nessus 2. We were already happy with the level of security in Nessus 2.

Ron Gula: It doesn't work that way. The 'attacker' would need to be in the network already to break into the Nessus scanner, and he'd have to wait for the scanner to scan them. It's something we considered when we designed Nessus 2 and Nessus 3.

I'm more concerned with the state of the system that Nessus is installed on top off than the security of Nessus. We have a lot of folks send us test output of running Nessus on 'localhost' and we always see older versions of SSH and running web servers. Even on Windows, when our NeWT users send in these sorts of reports we always see shares and missing patches.

If the forks of Nessus made a 'more secure' version of Nessus, then this could cause folks to try and use it. However, Nessus 2 is already out there and we have released patches for it already. These patches have not been picked up by some of the forked projects yet and I'm not sure if they are focused on security. If a security issues came up in the Nessus 2 code tree, we'd fix it.

Ron Gula: It depends what you mean by an active project. Tenable has already released point releases for Nessus 2 and when people find bugs in it we fix it. We have not seen any of the forks for Nessus even incorporate these fixes yet, but I am sure they will. I'm hoping that folks will innovate and add value to the tools that are out there. Unfortunately, aside from a few public Nessus 2 forks, most of the forks we are tracking or are aware of are by commercial groups who want to start with Nessus 2 to develop commercial scanner, a network monitoring tool or some other function.

Ron Gula: In lines of code to the Nessus daemon, very little. A lot of people asked for features and found bugs, but we had very little [very few] code submissions. On the vulnerability check side, we still accept checks written by folks outside of Tenable, but we also usually end up having to QA these checks and maintain them as time goes by. About 90% of the NASL checks come from Tenable.

Ron Gula: I am not sure. The adoption rate for Nessus is so far and wide. I just think the average user of Nessus isn't a coder. I speak to a lot of different open source project managers and they say similar stuff -- it's mostly free users and not really code contributors.