A Narrative Introduction to the Testing Security Tracker About ----- Everything that Testing Security does is publically available, as in "Debian doesn't hide problems" available. The best thing about our tracking 'system' is that it is very basic. There is no horrible overhead of web-based ticket/issue trackers, its just a subversion repository and some text files that we collaboratively edit and then some scripts to parse these files and generate useful reports available online. Everything is designed to be very simple to use, transparant and easy to see what other people are working on so you can work on other things. Why are these issues disclosed to the public? The way we look at it is that 99% of all vulnerabilities are already public, and 1% are vendor-sec/embargoed issues. Stable security deals with embargoed/vendor-sec issues, we don't, we deal with issues that have already been assigned CVE numbers (although we often times request these assignments), have been posted to common security mailing lists, or are seen in commit logs of software that is tracked (such as the Linux Kernel). It is our philosophy that if the Internet knows that there is a vulnerability in something, then we better know about it and the package maintainer needs to know about it and it needs to be fixed as soon as possible. It doesn't make sense to hide issues that everyone knows about already, in fact users have told us that they prefer to know not only when a package they have installed is vulnerable (so they can disable it or firewall it off, or patch it or whatever), but to also know that Debian is working on a fix. Transparancy is what our users expect, and what they deserve. Tracking publically known issues openly (and the occasional unfortunate embargoed issue privately) is good for the project as a whole, especially the public's perception of the project. Gentile Introduction -------------------- This following will give you a basic walk-through of how the files are structured and how we do our work tracking issues. There is much more that can be documented, but it is difficult to get all the issues notated and updated. It is easier to get a basic idea and then extrapolate from there how to do the rest. Ok, thats a bad excuse, so the full information should be filled in. The best way to understand is to check out our repository from subversion so you have the files on your computer and can follow along at home. To do this, you need an Alioth account, and then you just need to do the following: svn co svn+ssh://svn.debian.org/svn/secure-testing This will check out our working repository into a directory called secure-testing. Inside this directory are a number of subdirectories. The data directory is where we do most of our work. If you don't need write access, you can of course check out our files without an Alioth account as well: svn co svn://svn.debian.org/svn/secure-testing Automatic Issue Updates ----------------------- Twice a day a cronjob runs that pulls down the latest full CVE lists from Mitre, this automatically gets checked into data/CVE/list. We get notified via either email (http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits) of every SVN commit, by RSS feed (http://svn.debian.org/wsvn/secure-testing/?op=rss&rev=0&sc=0&isdir=1) or via the CIA bot on #debian-security on OFTC. For example, the bot will say in the channel: 17:14 < CIA-1> joeyh * r2314 /data/CVE/list: automatic CAN database update Most of our work is taking the new issues that Mitre releases and processing them so that the tracking data is correct. Read on for how we do this. Processing TODO entires ----------------------- The Mitre update typically manifests in new CVE entries. So what we do is to update our svn repository and then edit data/CVE/list and look for new TODO entries. These will often be in blocks of 10-50 or so, depending on how many new issues they have assigned. Depending on how you feel you will "claim" a block of say 10 new entries by putting your name in the file at the beginning and the end of the new TODO entries and then commit the repository. This looks like this: begin claimed by jmm CVE-2005-4066 (Total Commander 6.53 uses weak encryption to store FTP usernams and ...) TODO: check CVE-2005-4065 (SQL injection vulnerability in the search module in Edgewall Trac ...) TODO: check CVE-2005-4030 (SQL injection vulnerability in Quicksilver Forums before 1.5.1 allows ...) TODO: check end claimed by jmm Once these are checked-in, then others will not do work on these TODO issues. Issues Not-For-Us (NFU) ----------------------- Processing your claimed entires is done by first seeing if the issue is related to any software packaged in Debian, if it isn't a package in Debian and has no ITP then you note that in the file, for example: CVE-2005-3018 (Apple Safari allows remote attackers to cause a denial of service ...) NOT-FOR-US: Safari ITP packages ------------ If it is a package that someone has filed an RFP or ITP for, then that is also noted, so it can be tracked to make sure that the issue is resolved before the package enters the archive: CVE-2004-2525 (Cross-site scripting (XSS) vulnerability in compat.php in Serendipity ...) - serendipity (bug #312413) Packages in the archive ----------------------- If it is a package in Debian you look to see if the package is affected or not (sometimes newer versions that have the fixes have already been uploaded). If the version has been fixed already, note the package name and the Debian version that fixes it and assign a severity level to it, for example: CVE-2005-2596 (User.php in Gallery, as used in Postnuke, allows users with any Admin ...) - gallery 1.5-2 (medium) If it hasn't been fixed, I will determine if there has been a bug filed about the issue, and if not, I will file one and then note it in the list (again with a severity level): CVE-2005-3054 (fopen_wrappers.c in PHP 4.4.0, and possibly other versions, does not ...) - php4 (bug #353585; medium) - php5 (bug #353585; medium) Severity levels --------------- These levels are mostly used to prioritize the order in which security problems are resolved. Anyway, we have a rough overview on how you should assess these levels: unimportant: This problem does not affect the Debian binary package, e.g. a vulnerable file, which is not built or a vulnerable file in doc/foo/examples/ low : A security problem, which has only mild security implications and one would even be comfortable with if it continues to be present medium : A typical, exploitable security problem. high : A typical, exploitable security problem, which you'll really like to fix and at least implement a workaround. This could be because the vulnerable code is very broadly used, because an exploit is in the wild or because the attack vector is very wide. NOTE and TODO entries --------------------- There are many instances where more work has to be done to determine if something is affected, and you might not be able to do this at the time. These entries can have their TODO line changed to something descriptive so that it is clear what remains to be done. For example: CVE-2005-3990 (Directory traversal vulnerability in FastJar 0.93 allows remote ...) TODO: check, whether fastjar from the gcc source packages is affected It is also useful to add information to issues as you find it, so that when others go to look at an issue and want to know why you marked it as you did, or need a reference, it will be there. The more information left, the better. For example, the following entry lets you know that CVE-2005-3258 doesn't affect the squid that we have because the issue was introduced in a patch that was never applied to the Debian package: CVE-2005-3258 (The rfc1738_do_escape function in ftp.c for Squid 2.5 STABLE11 and ...) - squid (bug #334882; medium) NOTE: Bug was introduced in a patch to squid-2.5.STABLE10, NOTE: this patch was never applied to the Debian package. Distribution tags ----------------- Our data is primarily targeted at sid, as we track the version that a certain issue was fixed in sid. The Security Tracker web site (see below) derives information about the applicability of a vulnerability to stable and oldstable from the list of DSAs issued by the security team and the fact that a source package is part of a release. Distribution tags can be used to denote information about a vulnerability for the version of a package in a specific release. An example: CVE-2005-3974 (Drupal 4.5.0 through 4.5.5 and 4.6.0 through 4.6.3, when running on ...) - drupal 4.5.6-1 (low) [sarge] - drupal (Only vulnerable if running PHP 5) Drupal has been fixed since 4.5.6, however Drupal from Sarge still isn't vulnerable as the vulnerability is only effective when run under PHP 5, which isn't part of Sarge. TODO ---- Need to document , , REJECTED, RESERVED Generated Reports ----------------- All of this tracking information gets automatically parsed and compared against madison to determine what has been fixed and what is still waiting, this results in this page: http://spohr.debian.org/~joeyh/testing-security.html This page tells us a number of things, for example: abiword 2.2.10-1 needed, have 2.2.7-3 for CAN-2005-2964 This tells us that we know that this fix has been applied in debian package version 2.2.10-1, but testing only has 2.2.7-3. It has links to the reason why this hasn't entered testing yet, as well as the CAN reference at Mitre (given different background colors according to the severity). The ones with bugs have links directly to the bugs that have been filed. Additionally cross-references for DSAs are generated. At the bottom is a legend detailing the severity levels, the number of unfixed holes currently in testing, the number of holes that have been fixed in unstable that haven't migrated to testing, and the number of TODO items that we have to process still. TODO ---- Document Florian's tracker There is a more detailed tracker that is still under development, but provides a lot more views into this information, its here: http://idssi.enyo.de/tracker/ Following up on security issues ------------------------------- By simply loading this page and doing a little gardening of the different issues many things can be done. One thing is that you can read all the bug reports of each issue and see if new information has been added to the end that might provide updated or changed information (such as if an issue has been closed, or a version of the package has been uploaded that contains the fix). It is also useful to follow-up on the issues to prod the maintainer to deal with the issue, which they may have forgotten about. IRC Channel ----------- We hang-out on #debian-security on OFTC, stop by the IRC channel if you'd like, also we can add you to the alioth project so you have svn write permission and you can test drive it on the testing issues for however long you like to get an idea or feel comfortable (and hey it helps!) TODO: document {} cross refs document DSA/list document DTSAs document tsck