Auditing Package Prioritization Guidelines
When performing an audit of the Debian distribution one of the first problems is deciding which packages to examine.
Ideally all packages would be examined, but due to the sheer size of the archive there has to be a simple way of prioritizing the work.
As a simple set of guidelines the packages worth examination first are:
- Any binary which is installed setuid or setgid.
- Anything which provides a service over a network.
- Any remotely accessible CGI/PHP scripts.
- Anything which contains a cronjob or other automated script which runs with root privileges.
Popular packages should generally receive a higher priority, since any problems in them will affect a greater number of users.
The Debian Popularity Contest keeps a running survey to show what packages are most popular among the volunteers in the survey.
In particular, take a look at the packages sorted by vote.
by vote list ranks packages by how often they're used by the
people participating in the survey.
If a package is important to security, especially if it meets one of the criteria above, and it's popular (according to a survey like this one), then it's definitely a candidate for review.
setuid and setgid binaries
setuid and setgid binaries are the traditional targets for security audits, as compromising a vulnerable binary with either of these permissions can lead to a local user gaining access to privileges they shouldn't otherwise have.
To aid the search there is a list of all the setuid and setgid binaries contained in the current stable release.
When it comes to choosing these binaries it's important to remember that some such binaries are more security sensitive than others. setuid(root) binaries should be examined ahead of setgid(games) and setuid(bugs) for example.
Networking servers are another obvious source of inspiration when it comes to performing a security audit, as an exploitable problem in them could lead to attackers compromising machines remotely.
Remote compromises are usually much more severe than local compromises.
Online scripts, especially CGI scripts, are really in the same class as network servers — although your webserver itself may be secure the scripts which run upon it are just as important.
A bug in a script that is available across the network is as serious as a bug in a server listening for connections — both could allow your machine to be compromised equally.
Cronjobs and system services
Whilst there aren't many of these around it's worth looking at the automatic scripts, cronjobs, etc, which are included inside packages.
A lot of supporting things run as root by default for cleaning logfiles, etc.
Successful exploitation of a symlink attack could result in a local compromise.