English | Deutsch
Home »

Minutes of the Third Developer Conference (DevCon3, 2011)

These are the minutes taken during working sessions.

A significant amount of ideas and concepts were discussed and explored during the whole confrence. Some bilateral, several during evening/night and during the social events. This mostly did not end up in the minutes but surely will lead to improvements of OpenVAS over time.

Session: Interfacing

This session mainly brainstormed tools that OpenVAS interfaces with, which could also be coupled and how to improve some existing interfaces.

OMP interfacing: The Metasploit Bridge is a nice example on how other tools can issue OpenVAS for scanning.

Sourcefire 3D Center is a nice example how a tool be coupled via the Report Format Plugin and Escalator technology.

Nmap is a nice example how a tool is coupled via NVTs (here in order to collect detection data on ports, OS, Apps).

Session: Technology & Architecture

Moderator: Jan-Oliver Wagner
Minutes: Henri Doreau

Whiteboard content:

Scanner                            |   Manager      |  Other
---------------------------------- + -------------- +--------------------------
logging                            |  (Open)SCAP    |  OpenVAS-client 
OSP to replace OTP                 |  Easy retest   |  |_ 1) keep it silently compatible
Memory footprint                   |                |  |_ 2) wait for the OSP
Consistent error reporting         |                |  |_ 3) develop a new client
WMI                                |                |
SSH                                |                |
KB import/export (via NASL or OTP) |                |
|_ Tim will work on a prototype    |                |
* Reasons to replace OTP:
  - escaping and encoding is (half) broken
  - stateful protocol
  - 5+ workarounds currently deployed
but OSP dev. is not a blocker actually.
* SSH:
The old implementation (in NASL). No cipher but blowfish available
=> incompatible with many stacks). New implementation with libssh (technicals
problems with libssh2).

Should become a dependency for OpenVAS 5.
* WMI:
We cannot update to the latest samba code as it's now released under GPLv3.
Code we have is working but not maintained anymore. Seems to be the only
GPLv2-compatible version available.

Getting harder & harder to compile with moderns compilers (1000+ problems).
Hard to get libraries adopted by packagers because of that.
* Logging:
The scanner is logging to openvassd.dump & openvassd.messages.
  - not consistent (log, fprintf, display())
  - no rule on what to log

Proposal: log using the glib logging facilities

Differenciate the output of the NVTs and the logs of the scanner itself.

Should also be possible to report scanning failures to the user. Eventually
duplicate the information to the logfile.
* Memory footprint:
~100MB per process

Proposal to compile the NVTs by the main process. Also guarantees that the
exaclty same NVTs are executed even if the scan takes long & NVT's get updated
in between.

Worth trying the early load.
* Sighup handling:
Code from Nessus. Changing that would probably break start/stop.
|_ daemon will look for an openvassd in the PATH and start it (yeah that's bad...)

Break POSIX: don't die upon SIGHUP anymore, reload configuration files.

-- trends & future --

with CPEs and CVEs within the mng DB. => prognosis scan. Offer an option to
run a scan to confirm the presence of the vulnerability once the NVT is
available.

50k+ CVEs available.
(open)Scap integration => manager

Extremely slow updates observed for proprietary competitors. We can use the
DB for indexing in order to achieve fast upgrades.

Our DB does already support versioning.

We should maybe simply grab the RAW data and re-structure it using a custom
scheme. Do not necessarily stick to a 3rd part scheme.
SQLite:
  - exclusive locks
  - no replication, no transactions between 2 databases
  + handle concurrency for us
We can refer to CVEChecker or OSVDB to see sample implementations.

Ok to extend our storage requirements and require the user to have all the
CPE/CVE info stored on HD.

One CPE/line => easy diffs

Session: NVTs

Moderator: Tim Brown
Minutes: Michael Wiegand

Tim Brown states that while OpenVAS is currently very good at identifying vulnerabilities through package version detection during Local Security Checks (LSCs). This is being mostly automized and thus remote checks can and should receive even more attention.

Developing a process for identifying ways to remotely test is discussed; possible solutions include reverse engineering, collecting PCAP fragments or using blogs or specialized search engines like exploitsearch.net. This process could be centralized, e.g. through a ticket management system and it should be easy for users to submit fingerprints or signatures of new vulnerabilities, perhaps through a custom report format plugin.

Remote tests should not only be established for CVEs where we already have LSCs, but for yet not tested CVEs as well.

Another area which could use improvements is the remote detection of Cross-site scripting (XSS) vulnerabilities. A generator for XSS testing NVTs is suggested, similar to the LSC generator already in use. However, this would need a reliable source for signatures of XSS attacks.

A generator could also be used to prepare NASL scripts for any published CVE, but it is noted that such a generator would only be able to create a rough template and that the detail work would still have to be done by an NASL developer.

Tim proposes a "NASL Market" where users could vote on which NVTs they would like to see developed, allowing NASL authors to prioritize their NVT developments according to demand. Jan notes that such an approach would only make sense if the project could attract a larger number of NASL developers.

Jan notes that a number of NVTs are currently using the "security_note" function to display information which is of no security relevance and suggests using the "log_message" function for this class of message to reduce threat noise in the reports. While this proposal is generally supported it is also noted that this should be discussed further on the openvas-discuss mailing list to give users enough time to check for possible side effects of this change.

Jan asks how difficult it would be to create more tests for mobile devices. Tim replies that this is currently very difficult to do remotely without jailbreaking the device or having an agent running on it.

Error handling and reporting in NASL scripts is discussed. Currently, there are a number of possible scenarios which would prevent a script from completing its task, like a timeout, a missing external tool, a missing mandatory key, a scanner setting or a crash -- but the cases of a NVT finishing without result are rarely evaluated in OpenVAS Scanner and even almost never communicated properly to the user, leading to possible false negatives. It is agreed that this situation needs improvement, but it has to be decided if the logic should be implemented on the Scanner level or on the NASL level. Furthermore, it should be decided if error should be reported for individual NVTs or in an aggregated fashion. One way to report errors could be introducing a new message function similar to log_message or debug_message and handle it accordingly.

Jan mentions that some NVTs still contain references to CAN numbers which were replaced by CVEs by Mitre. Thomas volunteers to update the remaining NVTs.

On a side note, Henri notes that the OpenVAS release tarballs are currently neither signed cryptographically nor are checksums made available to check the integrity of the tarball. It is decided that for future release both signatures with the OpenVAS Transfer Integrity Key and MD5 and SHA1 checksum should be provided. Michael will integrate this in the documented release process.