Author: micah Date: 2005-12-08 23:58:15 +0000 (Thu, 08 Dec 2005) New Revision: 2985 Added: doc/narrative_introduction Log: Adding a narrative introduction to the testing security tracker Added: doc/narrative_introduction ==================================================================--- doc/narrative_introduction 2005-12-08 21:14:20 UTC (rev 2984) +++ doc/narrative_introduction 2005-12-08 23:58:15 UTC (rev 2985) @@ -0,0 +1,239 @@ + 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. + +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 <itp> (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 <unfixed> (bug #353585; medium) + - php5 <unfixed> (bug #353585; medium) + +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 <not-affected> (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. + + +TODO +---- + +Need to document [sarge], [woody], and other tags + + +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 severity levels +document DSA/list +document DTSAs +document tsck