A Narrative Introduction to the Testing Security Tracker About ----- Everything that Testing Security does is publicly 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, transparent 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. Transparency is what our users expect, and what they deserve. Tracking publicly 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. Gentle 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, and also syncs that file with other lists like data/DSA/list and data/DTSA/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 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 entries ----------------------- 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. IMPORTANT: make sure to read: http://lists.alioth.debian.org/pipermail/secure-testing-team/2009-May/002394.html Issues Not-For-Us (NFU) ----------------------- Processing your claimed entries 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. Another case are meta packages that only provide a downloader (e.g. flashplugin-nonfree). There is no way to mark such packages as we have no influence on the version and technically the code is not present in Debian. Example: CVE-2005-3018 (Apple Safari allows remote attackers to cause a denial of service ...) NOT-FOR-US: Safari There is a tool that helps with sorting out all the NOT-FOR-US issues: See "bin/check-new-issues -h". For the search functions in check-new-issues to work, you need to have unstable in your sources.list and have done "apt-get update" and "apt-file update". Having libterm-readline-gnu-perl installed helps, too. Unfortunately, check-new-issues does not yet support the "claimed by" tags mentioned above. Please also make sure to check the wnpp list for possible items and the ftp-master removal list to see if the issue way maybe present in the past but the package was removed Reserved entries ---------------- Several security problems have coordinated dates of public disclosure, i.e. a CVE identifier has been assigned to a problem, but it's not public yet. Also, several vendors have a pool of CVE ids they can assign to problems that are detected in their products. Such entries are marked as RESERVED in the tracker: CVE-2005-1432 RESERVED Rejected entries ---------------- Sometimes there are CVE assignments that later turn out to be duplicates, mistakes or non-issues. These items are reverted and turned into REJECTED entries: CVE-2005-4129 REJECTED 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, 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, we determine if there has been a bug filed about the issue, and if not, 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) Bug numbers can be added as in the example above. To avoid duplicate bugs, "bug filed" can be added instead of "bug #123456" when the bug report has been sent but the bug number is not yet known (however, it is more desirable to file the bug, wait for the BTS to assign a number, then update the entry in the CVE list so that complete information is always available in the tracker). The bug number is important because it makes it clear that the maintainer has been contacted about the problem, and that they are aware of their responsibility to work swiftly toward a fix. The bug numbers are also used to add additional references for the overview page and the Security Bug Tracker. They are parsed by a script that generates user tags "tracked" for the user debian-security@lists.debian.org, which enables BTS users to generate a query for all of the issues that are tagged "security" but not yet added to the tracker: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security;users=debian-security@lists.debian.org;exclude=tracked Since CVEs often drop in bulk, submission of multiple CVEs in a single bug report is permissable and encouraged. However, some maintainers have indicated a preference for only one issue per bug report. The following is a list of packages for which each CVE should be reported separately: - php5 A special exception is made for kernel related issues. The kernel-sec group will take care of them and file bugs if needed. If you wan't to report a bug, bin/report-vuln might be helpful in creating the bug report. If a vulnerability does not affect Debian, e.g. because the vulnerable code is not contained, it is marked as : CVE-2004-2628 (Multiple directory traversal vulnerabilities in thttpd 2.07 beta 0.4, ...) - thttpd (Windows-specific vulnerabilities) is also used if a vulnerability was fixed before a package was uploaded into the Debian archive. Sometimes there are cases, where a vulnerability hasn't been fixed with a code change, but simply by deciding that a package is that broken that it needs to be removed from the archive entirely. This is tracked with the tag: CVE-2005-1435 (Open WebMail (OWM) before 2.51 20050430 allows remote authenticated ...) - openwebmail After a new Debian release, some packages vanish from the database, and consistency checks might fail. In this case, a single entry needs to be added to an input file, or the package name should be included in the data/packages/removed-packages file. 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 source file, which is not built, a vulnerable file in doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't matter on Debian). All "non-issues in practice" fall also into this category, like issues only "exploitable" if the code in question is setuid root, exploits which only work if someone already has administrative privileges or similar. low : A security problem, which has only mild security implications (local DoS, /tmp file races and so on). medium : For anything which permits code execution after user interaction. Local privilege escalation vulnerabilities are in this category as well, or remote privilege escalation if it's constrained to the application (i.e. no shell access to the underlying system, such as simple cross-site scripting). Most remote DoS vulnerabilities fall into this category, too. high : A typical, exploitable security problem, which you'll really like to fix or 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. Should be put into that category anything that permits an attacker to execute arbitrary code on the vulnerable system (with or without root privileges) and high-impact denial-of-service bugs (for instance, an IPv4 forwarding path vulnerability which requires only very few packets to exploit). Significant defects in security software can be rated "high" as well (for instance, a vulnerability in a piece of cryptographic software which flags forged digital signatures as genuine). Certain packages may get higher or lower rating than usual, based on their importance. 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. CVE assignments --------------- Debian can only assign CVE names from its own pool for issues which are not public. To request a CVE from the Debian pool, write to and include a description which follows CVE conventions. To request a CVE for public issues, write to Mitre and possibly to the moderated oss-security list. In the meantime, you can add an entry of the form CVE-2009-XXXX [optipng array overflow] - optipng 0.6.2.1-1 (low) NOTE: http://secunia.com/advisories/34035/ in the data/CVE/list file. It is desirable to include references which uniquely identify the issue, such as a permanent link to an entry in the upstream bug tracker, or a bug in the Debian BTS. If the issue is likely present in unstable, a bug should be filed to help the maintainer to track it. Lack of CVE entries should not block advisory publication which are otherwise ready, but we should strieve to release fully cross-referenced advisories nevertheless. 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. 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 website: http://security-tracker.debian.net/ It incorporates package lists and parses distribution lists and can thus be used to - Present the security history of a package - Provide overviews of vulnerable packages in stable, testing, sid and oldstable (it still has some false positives, wrt packages in stable that are present in stable, but not vulnerable, but these will be ironed out soon). The oldstable data is likely inaccurate. - Generate a list of packages that are subject to security problems, but stuck in testing migration due to problems with the dependency chain and thus candidates for a DTSA - Generate a list of TODO issues that need to be addressed - Generate a list of packages that will enter Debian soon and need to be checked for security problems - Generate a list of provisional IDs that need to be turned into proper CVE entries - Show some potential problems in the data pool (e.g. misspelled package names not found in the packages list, or potentially missing epochs) For every security problem it displays - The CVE information - A severity assessment by NVD - Cross references to DTSAs, DSAs and bugs in the BTS - The status of a security problem in stable, oldstable, testing and sid - Additional notes from our tracker The DSA list ------------ We maintain a list of all DSA advisories issued by the stable security team. This information is used to derive information about the state of security problems for the stable and oldstable distribution. An entry for a DSA looks like this: [21 Nov 2005] DSA-903-1 unzip - race condition {CVE-2005-2475} [woody] - unzip 5.50-1woody4 [sarge] - unzip 5.52-1sarge2 NOTE: fixed in testing at time of DSA The first line tracks the date, when a DSA was issued, the DSA identifier, the affected source package and the type of vulnerability. The second line performs a cross-reference to the entry in CVE/list that maintains the state of the vulnerability in sid. Every entry that is added like this to DSA/list is parsed by a script and automatically added to CVE/list. The next lines contain the fixes for stable and optionally oldstable, addressed with distribution tags. You may add NOTE: entries freely, we use a NOTE entry for statistical purposes that tracks, when a fix has reached testing relative to the time when it hit stable. There is no need to add anything to CVE/list for a DSA, the DSA cross-reference will be added automatically by the cron job. However, you do need to add [sarge] or [woody] entries to CVE/list when there is a 'no-dsa' or 'not-affected' condition. The bin/dsa2list script can be used to generate a template for a new DSA entry once the official DSA is published on debian-security-announce. You should not blindly trust the script output and double-check it, though. Checking your changes --------------------- Commits are checked for syntax errors before they are actually committed, and you'll receive an error and your commit is aborted if it is in error. To check your changes yourself beforehand, use "make check-syntax" from the root of the svn directory. 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 DTSAs document tsck document tracked tag