Conducting an audit

This page gives a rough overview of the steps necessary to conduct an audit of a package.

The first step is to actually choose a package to examine, you should pick one that's more critical to security.

See the list of packages that we think are most important to audit for suggestions on how to make your decision.

One thing that should be made clear is that we are not trying to make sure that a package is only audited once. If many people choose to examine the same package this is a good thing, as it demonstrates that many people believe the package is security sensitive.

By allowing an essentially random selection of packages we simplify coordination and we eliminate the problem of how can you trust person X to do a good job? (We don't need to as it is assumed that sooner or later somebody else will choose to examine the same program).

Starting the audit

After making your package selection you actually need to start the audit.

If you're not sure about the kind of problems you're looking for first start by reading a book on how to develop secure software.

The Secure Programming for Linux and Unix HOWTO has a lot of good information that can help you. Secure Coding: Principles & Practices by Mark G. Graff and Kenneth R. van Wyk is also an excellent book.

Although tools are imperfect, they can still be extremely helpful in finding likely vulnerabilities, See the auditing tools page for more information on some of the available auditing tools and how they are used.

As well as looking at the code itself it is a good idea to read the documentation of the package itself, and try installing it and using it.

This might allow you to think of ways to subvert the program in its typical operation.

Reporting Problems

If you do discover a problem within the package that you are examining it then you should report it. When reporting a security bug try to provide also a patch for it so that the developers can fix it in a timely fashion. There is no need to provide an attack sample (often called an exploit or proof of concept) since the patch should speak for itself, it is usually best to invest time in provide a proper patch that to provide a successful attack that exploits the bug.

Here is a list of recommended steps once you have found a security bug in Debian:

  1. Try to produce a patch for the bug or obtain sufficient information so others can determine the bug's existence. Ideally each report should contain a fix for the problem which you have discovered, which has been tested and verified to actually close the problem.

    If you do not have a fix then the more detail you can give on the scope of the problem, the relative severity of the issue and any workarounds the better.

  2. First review if the security bug is present in the stable Debian release or if it might be present in other distributions or in the version provided by upstream maintainers.
  3. Based on the above review, report the issue:
    • To the upstream maintainer through their security contact e-mail, provide the analysis and the patch.
    • To the Debian Security Team if the bug is present in a released Debian version. The Debian Security Team will typically assign a CVE name to the vulnerability. The security team will coordinate with any other Linux Distributions if necessary and contact the package maintainer on your behalf. You can, however, send a copy of the mail also to the package maintainer. Do so only when handling low risk vulnerabilities (see below).
    • If the bug is not present in a released Debian version and the application might be present in other distributions or operating systems then mail vendor-sec (a private mailing list most free-software distributions use to discuss about security bugs). You don't need to do this if you have already sent the bug to the Debian Security Team as they will forward it to this list too.
    • If the bug is not present in any released Debian version and you are absolutely sure that the application is not included in any other distributions or operating system then report it through the Bug Tracking system.
  4. Once the vulnerability is public (i.e. when the Debian Security Team or other vendor has issued an advisory) then a bug with all the relevant information should be filed in the Debian Bug Tracking System to keep track of the security issue in unreleased Debian versions (i.e. sid or testing). This is usually done by the Security Team itself, if you find that they have missed this or you are not reporting this to the Security Team then you can report it yourself. Make sure you tag the bug appropriately (use the security tag) and that you set the proper priority (usually grave or higher). Also make sure that the bug title includes the proper CVE name if one has been assigned to it. This provides a way to keep track of security bugs so that they are fixed both in the released and unreleased Debian versions.
  5. If you wish, once the issue is public, you can forward this information to public full disclosure mailing lists such as full-disclosure or Bugtraq.

Notice that these steps might depend based on the risk associated with the vulnerability found. You need to assess the risk based on:

Different steps should be taken, for example, to report a local symlink attack that can only be used by authenticated users and only provides a way to damage the system than to report a remote buffer overflow that provides administrative privileges and is present in software which is in widespread use.

In most cases, as most security bugs shouldn't be disclosed generally until after they have been fixed do not report them via the standard Debian Bug Tracking System, instead first report the problem directly to the Security Team who will handle the release of an updated package and, once fixed, report them to the BTS.