Trusted NVTs (how to manage NVT signatures)

This text explains what you need to do to allow your OpenVAS server to execute only signed NVTs with a trust level you decide.

Currently, you get some signed NVTs by using the command "openvas-nvt-sync" which is included in openvas-plugins since release 0.9.1. The signatures correspond to the certificate "OpenVAS Transfer Integrity" given at the bottom.

What is a signature (in simple words)?

A clever method is applied to compute a unique checksum for a file. If only a single character in the file changes, the checksum will change as well.

This checksum is digitally signed in a way that you can test with a public certificate whether a certain key was used to create the signature. Such a key and certificate do always form a pair that is related to each other.

If the signed file has been modified by a third party, the signature will be broken. In this case you should not trust the file.

If the signature is not broken, the question remains if you trust the owner of the key. If you decided to do so (and there any many ways and supporting technologies to manage this), you can accept the file as trustworthy.

The signature format

The signatures for OpenVAS NVTs and associated files (.nasl, .inc and .nes) are standard so-called "ASCII-armored detached OpenPGP signatures" created with GnuPG. This format features:

• multiple signer keys possible
• site administrators can decide which keys to trust
• signatures can be created and verified with widely available tools like GnuPG
• detached signatures do not require changes to the signed file (like inline signatures would)

The name of the signature file is the name of the signed file with the added extension ".asc". That is, the name of the signature file for a file "myscript.nasl" is "myscript.nasl.asc".

Note difference to Nessus: Nessus signatures were inline x509-based signatures. The concept does not consider multiple signatures. A standard problem of inline signatures is that you can place bad code around a valid block. Whether such injection of untrusted code works for Nessus has not been tested by the OpenVAS team, though.

The signature verification process

The signature verification of the OpenVAS server is activated by setting "nasl_no_signature_check = no" in /etc/openvas/openvasd.conf.

At start-up time of the openvas daemon (openvasd), all signatures are checked for validity. Only fully trusted files are considered by the server and thus loaded and made available to OpenVAS client.

The trust check uses a special list of certificates managed for the OpenVAS server. It is a standard GnuPG keyring located by default in /etc/openvas/gnupg.

When OpenVAS verifies a signature it checks all signatures contained in the signature file and all signatures must be fully valid. This means that all of the following criteria must be fulfilled for all signatures:

1. The certificate must be present in the keyring.
2. The key must be fully valid.
3. The signature must be valid.

If any of the signatures does not meet all of these criteria, the file is considered untrustworthy and will not be executed at all. If all signatures meet the criteria, the script is trusted fully and may execute any functions. If no signature file exists, the script is not executed at all.

Note difference to Nessus: For Nessus signatures, three levels were distinguished: no signature, bad signature and good signature. Plugins with no signature were still executed, but in some "restricted" mode where no functions can be executed that are regarded critical like "fwrite". OpenVAS explicitly only distinguishes between fully trusted and not fully trusted files.

How to add a certificate

To add a certificate to the OpenVAS Server keyring issue this command:

# gpg --homedir=/etc/openvas/gnupg --import certificate-file.asc

See at the bottom for available certificate files.

Initial preparation to set trust: create key

To express trust to keys that signed NVTs (see "How to set trust" below) you need a signing key for your OpenVAS installation. You can use an existing key you already have, or you can generate a new one:

# gpg --homedir=/etc/openvas/gnupg --gen-key

This needs to be done only once for a OpenVAS Server installation.

How to set trust

For OpenVAS to trust a signature, the key used to create the signature has to be valid. A certificate corresponding to this key that was just imported has unknown validity and thus is not valid.

To set a certificate trusted for your purpose, you have to sign it. The preferred way is to use local signatures that remain only in the keyring of your OpenVAS Server installation.

To finally sign a certificate you need to know its KEY_ID. You either get it from the table at the bottom or via a "list-keys" command. Then you can locally sign:

# gpg --homedir=/etc/openvas/gnupg --list-keys

# gpg --homedir=/etc/openvas/gnupg --lsign-key KEY_ID

Before signing you should be absolutely sure that you are signing the the correct certificate. You may use its fingerprint and other methods to convince yourself.

How to remove a certificate

# gpg --homedir=/etc/openvas/gnupg --delete-keys KEY_ID

Manual signature verification

In case you want to manually verify the validity of a .nasl file, you need to do the following:

To verify signatures on the command line, you can either run GnuPG:

$ gpg --homedir=/etc/openvas/gnupg gpg --verify script.nasl.asc script.nasl

Or you can use the standalone nasl interpreter:

$ openvas-nasl -p script.nasl

The -p Option means that the script is only parsed and not executed.

To debug the signature verification done by the nasl interpreter, use the -T Option to enable the trace mode. The signature verification will leave some detailed information about the verification and the signatures found in the trace file.

Overview on existing certificates

Certificate Name	ID	Download	Owner(s)	Description
OpenVAS: Transfer Integrity	48DB4530	OpenVAS_TI.asc	OpenVAS Development Team	This certificate signs .nasl and .inc scripts as they entered the OpenVAS source code repository or as they were updated. Thus, a valid signature means that the script has not been modified on the way between the OpenVAS distribution point and your OpenVAS installation. The presence of a signature does NOT MEAN ANY JUDGEMENT of the script itself. It only helps to verify integrity after transfer. The scripts are WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.