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 succesful attack that
exploits the bug.
Here is a list of recommended steps once you have found a security
bug in Debian:
- Try to produce a patch for the bug or obtain sufficient
information so others can determine the bug's existance. 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.
- 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.
- 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.
- 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 appropiately (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.
- 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:
- If the vulnerability is remote or local.
- The consequences of the vulnerability if exploited.
- The widespread usage of the software affected by the vulnerability.
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.
