OpenVAS Project Ideas for Google Summer of Code 2010

The OpenVAS Team will apply for the Google Summer of Code 2010 Program! If you have ideas, comment etc. subscribe to the openvas-discuss mailinglist and post them there or contact me directly. Also feel free to join the irc channel.

General

OpenVAS stands for Open Vulnerability Assessment System and aims to be the number #1 network security scanner. It is capable of performing remote and local security checks. Over 16000 security check modules are available, which are written in a small interpreted language called NASL. With NASL it is also easy to write wrappers for other tools like nmap. Basic support for OVAL definitions is also implemented. Currently, OpenVAS is used by academics, governments and companies around the world in order to find and fix vulnerabilities. So far, two major version revisions (2.x and 3.x) have been released. We have held two succesful OpenVAS developer conferences. The last developer conference attracted 16 developers coming from four continents.

This will be the first year for OpenVAS to participate in the Google Summer of Code program and we would be more than happy if you want to join and support us.

General Student Requirements

• We are communicative, so we expect a high online availability, meaning that you should respond to emails and - if possible - hang around in the irc channel.
• It goes together with communicational skills, you need to be able to communicate in English without sounding rude :).
• We expect you to write weekly reports to the openvas-devel mailing list, in wich you summarize your last week and give an outlook for the week to come.
• Understand the basic idea behind Change Requests. You might have to create one.
• You should generally be comfortable with a common linux environment.
• For the benefit of everybody, you will have to document and format the written code, probably to your own dislike (its boring and you might disagree about readability of chosen GNU coding style).
• Other projects-specific requirements might be listed in the projects ideas below.

List of Project Ideas

(Can still be worked on.)

• There was some discussion on the irc channel
• and on the openvas-discuss mailinglist.
• For starters, you can look at the open Change Requests
• and on the notes from the latest developer conference.

Your Idea

Let us know your ideas, we are open and friendly. Sometimes we do not see the obvious, thus do not think "Uuuuh, I just don't know OpenVAS all that well, it must have been meant to be like that.".

Facilitate a Documentation System for NASL Scripts and Include Files

During the last developer conference, the developers agreed that documentation of NASL- scripts and the NASL- "libraries" (really just included files) would be a good thing. NASL supports comments, but there is no way to turn these into documents yet. Also, there are no conventions about how comments should be written.

A basic example (from smbt.inc, already documented not too bad):

#-----------------------------------------------------------------#
# Convert a netbios name to the netbios network format            #
#-----------------------------------------------------------------#
function netbios_name(orig){
    return netbios_encode(data:orig, service:0x20);
}

could in javadoc syntax look like

/**
 * @brief Converts a netbios name to the netbios network format.
 * @param[in] orig The netbios name to convert to netbios format.
 * @return The argument \ref orig converted to netbios network format.
 */
function netbios_name(orig){
    return netbios_encode(data:orig, service:0x20);
}

A couple of frameworks allow automatic generation of code documentation for various languages. For the C code, the OpenVAS project uses Doxygen. In the Doygen FAQ #12 three options are given how to deal with situations, where Doxygen doesnt support a given language natively. As NASL is not so incredibly far away from C, a filter could be written that transforms NASL into something similar enough to C and process this output with doxygen.

Depending on the background of a possible student, it might be worth to explore different code documentation generators first and to find out which one is easiest to adjust to the NASL syntax and requirements.

General Feature Enhancements

There are always features to be added, some of which are more appropriate for people with certain background knowledge.

• Store uploaded files in memory: NVTs might have preferences, which have a certain type (e.g. string). One of these types is "file", where a user is allowed to send the NVT a file. Currently, the user-uploaded files are stored on disk. This is however not necessary for all plugins to behave correctly. These cases should be identified and a strategy to store uploaded files just in memory should be found.
• Improve logging, add syslog support: Currently, only the rather new modules openvas-manager and openvas-administrator make use of the openvas-logging system (which is backed by GLibs logging mechanisms). Older code from openvas-libraries and openvas-scanner should use these new possibilities, too. Also, basic syslog support was added, but could not yet be tested and explored in detail. Strategies shall be found on how to switch to the newer logging mechanisms without it being a boring task (search/replace).
• Improve omp-cli: The omp-cli, command line interface to an OMP server like the openvas-manager, can be improved by adding command aliases to common omp- commands. Currently, many commands are only executable by entering the whole omp elements, where some examples of shortcuts do already exist. Also, the omp-cli could be made interactive, instead of issueing one command per call. This includes interactive input for host, username, password etc, such that these values cannot be peeked at when looking at the process list.

Reuse and Improve Code Quality Measurement Scripts

For releases prior to OpenVAS 3.0, we collected data from various tools and scripts in an attempt to make code quality to some extend measurable.

The idea is to collect as much data as possible from tools and scripts (e.g. flawfinder, rats, cppcheck, doxygen warnings about missing comments, all gcc warnings it can throw etc), draw a sweet graph and make it a nice tool. The results should be updated with each release, but ideally generated often (e.g. before each commit).

As a nice outcome, a student would learn something about disputable coding style and might fix e.g. a memleak here or there.

Student Questionnaire

Basic/Contact Information

1. Your Name:
2. Your Email Address:
3. Favorite Nick:
4. If you have a URL for your resume/CV, please list it here:
5. If you wish to list any personal/blog URLs, do so here:
6. Where will you spend your time this summer?
7. How much time per day/week do you expect to have for this project?
8. Please list jobs, summer classes, and/or vacations that you'll need to work around:

Skills/Experience

1. Please describe in a few lines your C/C++ knowledge or experience (if any):
2. Please describe any Perl, NASL, OVAL, or other scripting language knowledge/experience:
3. Please describe any vulnerability scanning experience:
4. Please describe any UNIX development experience:
5. Please describe any previous OpenVAS usage experience:
6. Please describe any previous Open Source development experience:
7. Have you participated in any previous Summer of Code projects? If so, please describe your projects and experience. Be sure to mention the years involved and the name of your former mentors.
8. Have you participated in any collaborative effort in writing code? If so, please describe the project and experience.
9. Have you applied for (or intend to) any other 2010 Summer of Code projects? If so, which ones?

Project Selection

1. Top Project Choice (if choosing one from the OpenVAS ideas page):
2. Are you willing and able to do other projects instead?

Project Proposal

1. Please describe your proposed project in detail, including deliverables and expected timeline with milestones (this is the long answer):
2. Why are you well suited to perform this project?