diff options
Diffstat (limited to 'xml/htdocs/security/en/coordinator_guide.xml')
| -rw-r--r-- | xml/htdocs/security/en/coordinator_guide.xml | 1203 |
1 files changed, 1203 insertions, 0 deletions
diff --git a/xml/htdocs/security/en/coordinator_guide.xml b/xml/htdocs/security/en/coordinator_guide.xml new file mode 100644 index 00000000..3f51374e --- /dev/null +++ b/xml/htdocs/security/en/coordinator_guide.xml @@ -0,0 +1,1203 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<guide link="/security/en/coordinator_guide.xml"> +<title>GLSA Coordinator Guide</title> +<author title="Author"> + <mail link="koon@gentoo.org">Thierry Carrez</mail> +</author> +<author title="Author"> + <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail> +</author> +<author title="Author"> + <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail> +</author> +<author title="Author"> + <mail link="rbu@gentoo.org">Robert Buchholz</mail> +</author> + +<abstract> +This document contains procedures, tips and tricks applying to the +GLSA Coordinator job. +</abstract> + +<!-- The content of this document is licensed under the CC-BY-SA license --> +<!-- See http://creativecommons.org/licenses/by-sa/1.0 --> +<license/> + +<version>0.8.8</version> +<date>2008-05-09</date> + +<chapter> +<title>Prerequisites</title> +<section> +<title>Accounts</title> +<body> + +<p> +A certain number of accounts must be established before working as a GLSA +coordinator. To draft GLSAs you must get a +<uri link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri> account. To +manage security bugs you need to have a +<uri link="https://bugs.gentoo.org">Bugzilla</uri> account, which will be +upgraded to <c>editbugs</c> privileges. To send GLSA announcements you +need to have a yourname@gentoo.org address (i.e. to be a Gentoo developer). +This address should be allowed to send to gentoo-announce. +To commit XML GLSAs you need your developer account to be upgraded with +commit access to the GLSA directory in the <c>gentoo</c> CVS repository. +Finally you need an IRC name. You will be required to hang out in the +#gentoo-security channel whenever you're available online. +</p> + +<note> +All the names used should be consistent in order to allow easy identification. +</note> + +</body> +</section> +<section> +<title>GPG key</title> +<body> + +<p> +You must create a GPG key for your yourname@gentoo.org email address. You +can either create a specific key or add the gentoo.org address to an +existing key. The key ID should be <uri +link="/proj/en/infrastructure/ldap.xml">set in the LDAP</uri>, and you +should check +that your name and key ID appears on the +<uri +link="/proj/en/devrel/roll-call/userinfo.xml">developer +list</uri>. It is very important that the key is published at least on +the <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver. +It can also be submitted on other keyservers. +</p> + +</body> +</section> +<section> +<title>Environment</title> +<body> + +<p> +You must setup a CVS environment on your home machine to be able to commit +your GLSAs to the tree. +This is done by checking out a part of the <c>gentoo</c> CVS repository to a +given directory (for example ~/gentoo_cvs): +</p> + +<pre caption="Setup CVS environment"> +you@home you $ <i>mkdir gentoo_cvs</i> +you@home you $ <i>cd gentoo_cvs</i> +you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i> +you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i> +you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i> +</pre> + +</body> +</section> +<section> +<title>Mailing-list subscriptions</title> +<body> + +<p> +To be able to post to the lists where we publish our GLSAs, you must +subscribe your yourname@gentoo.org address to them: +</p> + +<table> + <tr> + <th>List</th> + <th>Subscription page</th> + </tr> + <tr> + <ti>bugtraq@securityfocus.com</ti> + <ti><uri>http://www.securityfocus.com/archive</uri></ti> + </tr> + <tr> + <ti>full-disclosure@lists.grok.org.uk</ti> + <ti><uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri></ti> + </tr> +</table> + +<note> +You can subscribe to a digest version of Full-Disclosure. +</note> + +<p> +As a security developer, you will be added to the gentoo-core list and +security@gentoo.org alias. You should also subscribe to gentoo-announce, +gentoo-dev and gentoo-security. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>Security bug types and Bugzilla components</title> +<section> +<body> + +<p> +All security bugs are located in the <c>Gentoo Security</c> Bugzilla product. +If you find a security bug which does not have the correct product name, +please fix it immediately. There are several different types of security bugs, +and each has its own component. +</p> + +</body> +</section> +<section> +<title>Vulnerability</title> +<body> + +<p> +Vulnerabilities are security bugs in the upstream software or introduced in +the Gentoo ebuild packaging. These bugs result in GLSAs. Kernel bugs have +their own category and should not filed as <c>Vulnerability</c>. +</p> + +</body> +</section> +<section> +<title>Kernel</title> +<body> + +<p> +Kernel vulnerabilities are treated using a separate procedure. To easily +distinguish them from the other bugs, they are filed under the <c>Kernel</c> +category. Kernel bugs do not result in GLSAs but have their own publication +system (Gentoo KISS). +</p> + +</body> +</section> +<section> +<title>Default config</title> +<body> + +<p> +Gentoo packages should be as secure by default as possible. Default +configuration bugs are filed when the default configuration shipped with the +package can be improved in terms of security. <c>Default config</c> bugs do +not generate GLSAs. +</p> + +</body> +</section> +<section> +<title>Auditing</title> +<body> + +<p> +Vulnerabilities that are found by Gentoo developers should be double-checked +before going out in the open (to upstream developers or security lists). They +are filed as Confidential Bugs (see below) and with the <c>Auditing</c> +component. When the finding has been verified they are switched to +<c>Vulnerability</c>. +</p> + +</body> +</section> +<section> +<title>Restricted bugs</title> +<body> + +<p> +Sometimes a bug is communicated to us under the promise we'll keep it secret +until a public release, usually known as the embargo date or coordinated release date. +Restricted bugs have the "Gentoo Security" checkbox +checked and therefore can only be accessed by Gentoo Security Team members. +External people (package maintainer, arch testers, Release Engineering) may be +added on a per-name basis, aliases should never be used (because they are too +wide and won't allow bug comments). +</p> + +<p> +There are three different types of restricted bugs. The first (and most secret) +ones are the <c>CLASSIFIED</c> bugs. A bug is classified when it contains +information that should never be released. This includes quotes of personal +emails sent to restricted mailing-lists or non-public intermediary patches. +Classified bugs are identified by the <c>CLASSIFIED</c> keyword in their Status +Whiteboard. Once CLASSIFIED, a bug cannot go back to unclassified status unless +at least two security managers agree to declassify it. +<c>CLASSIFIED</c> bugs should never be opened (unrestricted). +</p> + +<p> +The second type of restricted bugs is <c>CONFIDENTIAL</c> bugs. These are bugs +that contain information that should be kept secret until an agreed-upon +coordinated release date. No part of the bug (affected package name, +description, proposed patch or whatever) should ever leak outside the bug. +Patches must NOT be committed to portage CVS. +</p> + +<p> +The third (and less secret) type of restricted bugs is the <c>SEMI-PUBLIC</c> +bugs. Semi-public bugs should be kept secret, but patches may be committed to +portage. This is generally when the vulnerability is not known to the general +public but could be accessed by anyone (patch in upstream CVS for example). +</p> + +</body> +</section> +</chapter> +<chapter> +<title>Public vulnerability bug management</title> +<section> +<title>Status whiteboard rules</title> +<body> + +<p> +The status whiteboard in Bugzilla lets us keep track of the security bug +resolution steps. It should be following this pattern: "RATING [status] +coordinator", where: +</p> + +<table> +<tr> +<th>Element</th> +<th>Content</th> +<th>Example</th> +</tr> +<tr> +<ti>RATING</ti> +<ti>The vulnerability rating, following current policy rules</ti> +<ti>B3</ti> +</tr> +<tr> +<ti>[status]</ti> +<ti>The bug status, with optional extra information</ti> +<ti>[ebuild+]</ti> +</tr> +<tr> +<ti>coordinator</ti> +<ti>The nickname of the coordinator assigned to the bug, optional</ti> +<ti>koon</ti> +</tr> +</table> + +<p> +The following statuses are accepted: +</p> + +<table> +<tr> +<th>Status</th> +<th>Description</th> +</tr> +<tr> +<ti>upstream</ti> +<ti>Waiting for upstream developer to publish a new version or patch</ti> +</tr> +<tr> +<ti>upstream+</ti> +<ti>No response from upstream</ti> +</tr> +<tr> +<ti>ebuild</ti> +<ti>Waiting for the Gentoo package maintainer to provide a fixed ebuild</ti> +</tr> +<tr> +<ti>ebuild+</ti> +<ti>No response from the maintainer, considering a security bump</ti> +</tr> +<tr> +<ti>stable</ti> +<ti>Waiting for arches to mark the package with the appropriate keywords</ti> +</tr> +<tr> +<ti>stable+</ti> +<ti>Some arches are taking too long to mark the package appropriately</ti> +</tr> +<tr> +<ti>glsa?</ti> +<ti>Security must make a decision on whether a GLSA is needed</ti> +</tr> +<tr> +<ti>glsa</ti> +<ti>Waiting for the coordinator to send his GLSA</ti> +</tr> +<tr> +<ti>glsa+</ti> +<ti>The GLSA is late, any GLSA coordinator can correct and send it</ti> +</tr> +</table> + +<p> +The following extra information is admitted: +</p> + +<table> +<tr> +<th>Extra information</th> +<th>Description</th> +<th>Corresponding statuses</th> +</tr> +<tr> +<ti>tomask</ti> +<ti>When a package.mask has been requested against the package</ti> +<ti>upstream+, ebuild+</ti> +</tr> +<tr> +<ti>masked</ti> +<ti>if the package was masked as a temporary solution</ti> +<ti>upstream+, ebuild+</ti> +</tr> +<tr> +<ti>Arch names</ti> +<ti>When only one or two supported arches are blocking the bug</ti> +<ti>stable+</ti> +</tr> +<tr> +<ti>tempglsa</ti> +<ti>When a temporary GLSA was issued as a temporary solution</ti> +<ti>upstream+, ebuild+</ti> +</tr> +<tr> +<ti>blocked</ti> +<ti>When the bug is blocked by another bug</ti> +<ti>(any)</ti> +</tr> +</table> + +<p> +Examples: +</p> + +<table> +<tr> +<ti>C0 [stable]</ti> +</tr> +<tr> +<ti>A3 [ebuild] jaervosz</ti> +</tr> +<tr> +<ti>B1 [stable+ amd64] koon</ti> +</tr> +</table> + +</body> +</section> +<section> +<title>Determining original bug status</title> +<body> + +<p> +When the fix is not available from the upstream developer and/or there is +no official patch to solve the problem, the bug is in [upstream] status. If +the solution must be found amongst Gentoo developers, the bug is in [inhouse] +status. If a fix is available, the bug is in [ebuild] status. +If a fix ebuild is put +in the portage tree, the bug is in [stable] status. When the fix ebuild is +in portage with all required keywords set, the bug is in [glsa] status. +</p> + +</body> +</section> +<section> +<title>Bugs in [upstream] status</title> +<body> + +<p> +In [upstream] status, we wait for the fix version or a decent patch to +appear. This status requires to regularly check upstream for information: +development and announce mailing lists, websites, Bugs database, CVS when +available, are all relevant sources of information. Unofficial patches must +be taken into account only if the upstream developer does not react to the +vulnerability, and they must be thoroughly double-checked to ensure they +are not evil. When a fix version is announced or a patch is found, the bug +enters [ebuild] status. +</p> + +<p> +If there is no reaction from upstream and no patch, we enter [upstream+] +status. The only option here is to security-mask the vulnerable package +and issue a temporary GLSA if needed. See the policy for more details on the +security masking approval procedure. The status whiteboard should then be +flagged with masked and/or tempglsa keywords and bug severity set to +<c>enhancement</c>. +</p> + +</body> +</section> +<section> +<title>Bugs in [ebuild] status</title> +<body> + +<p> +In [ebuild] status, we must identify the maintainer of the package, and +summon him to commit a fix ebuild. Sources to identify the herd or developer +responsible for maintaining a package are the metadata.xml file in the +directory of the package in portage and the Changelog file showing who did the +latest version bumps. You should Cc: the herd and/or maintainer responsible +for the package on the bug and ask him to provide an ebuild for the fix +version. You should periodically check that an ebuild wasn't committed +to portage without any comment on the bug (it happens). When the ebuild +appears, the bug enters [stable] status. +</p> + +<p> +If the maintainer doesn't show up, we enter [ebuild+] status. In case a fixed +version is available, you should test if a simple version bump (renaming the +ebuild to the version and emerging it) works. If only a patch is available, you +should test if it applies cleanly. Then you should find a security bug wrangler +with x86 commit rights to do the bump and mark the ebuild ~ for testing. +</p> + +<p> +If the bump is not easy and/or any problem is detected with the bumped ebuild, +the only option is to security-mask the unmaintained package and issue a +temporary GLSA if needed. See the policy for more details on the +security masking approval procedure. The status whiteboard should then be +flagged with masked and/or tempglsa keywords and bug severity set to +<c>enhancement</c>. +</p> + +</body> +</section> +<section> +<title>Bugs in [stable] status</title> +<body> + +<p> +In [stable] status, you have to determine what KEYWORDS the provided ebuild +needs before the GLSA can go out. This can be tricky. You have to consider +every version currently in portage so that the fix ebuild has <e>equally or +more stable</e> keywords than any other packages in portage. Here is an +example: +</p> + +<table> +<tr> +<th>Versions</th> +<th>Keywords</th> +</tr> +<tr> +<ti>Affected</ti> +<ti>x86 ~ppc ~ia64</ti> +</tr> +<tr> +<ti>Affected</ti> +<ti>x86 ppc</ti> +</tr> +<tr> +<ti>Affected</ti> +<ti>~x86 ~ppc ~ia64</ti> +</tr> +<tr> +<ti>Fix must have:</ti> +<th>x86 ppc ~ia64</th> +</tr> +</table> + +<note> +You can use <uri>http://packages.gentoo.org</uri> to help you determine +the needed KEYWORDS. If affected packages were removed by the package +maintainer too early, you should use the +<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS access</uri> +to dig in the Attic and look for old KEYWORDS. +</note> + +<p> +Once determined (and noted for reference on the bug) the needed KEYWORDS, +you should Cc: arch teams and ask them to mark the ebuild stable or ~ +accordingly. To make sure that the arch teams will pick the bug up, don't forget +to add "STABLEREQ" to the bug's "Keywords" field. The arches alias are +archname@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). All arches (including +"unsupported" arches) must be called. But note that only "supported" arches (as +defined in the policy) are needed before the bug can advance to [glsa] status +You should periodically check for new keywords in the ebuild, as sometimes they +are changed without a comment in the bug. As soon as the required KEYWORDS +are in the ebuild for all supported arches, the bug enters [glsa] status. +</p> + +<p> +During a release preparation period you should also Cc: Release Engineering +(release@gentoo.org) on all bugs with [stable] status. +</p> + +<p> +If the arch teams take too much time testing and changing the KEYWORDS, or +they refuse to mark stable a package due to outstanding problems, the bug +enters [stable+] status. We must track down arch-maintainers to have them +mark stable, help testing. You should also convince the arches that if they +discover a bug in the ebuild that already was in previous "stable" versions, +the ebuild should be marked "stable" anyway, even if it's not really stable, +as specified in the policy. If the KEYWORDS can't be met, the only other +option is to security-mask the package: there is no acceptable unaffected +version, so it is like if no acceptable upstream fix was provided. +</p> + +</body> +</section> +<section> +<title>Bugs in [glsa] status</title> +<body> + +<p> +In [glsa] status, the security bug is corrected. We need to issue the GLSA +or close the bug without GLSA. The policy determines the cases where a GLSA +is needed and where a GLSA is not needed. There are also cases where a GLSA +vote must take place to decide if a GLSA is needed ([glsa?] status). +If at least two Security Team members vote for "no GLSA", then no GLSA should +be issued. The bug remains in [glsa] status until a GLSA is published. +</p> + +<p> +When a GLSA is needed but nothing was sent, the bug enters [glsa+] status. +It's the case when the assigned GLSA coordinator did not draft and/or +made peer-reviewed and/or sent his GLSA. Other members of the Security Team +should take the lead at this point and finalize the GLSA. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>Confidential vulnerability bug management</title> +<section> +<title>Status whiteboard rules</title> +<body> + +<p> +Confidential bugs should be following this pattern: "RATING [status] +coordinator KEYWORD CRD", where: +</p> + +<table> +<tr> +<th>Element</th> +<th>Content</th> +<th>Example</th> +</tr> +<tr> +<ti>RATING</ti> +<ti>The vulnerability rating, following current policy rules</ti> +<ti>B3</ti> +</tr> +<tr> +<ti>[status]</ti> +<ti>The bug status, with optional extra information</ti> +<ti>[ebuild+]</ti> +</tr> +<tr> +<ti>coordinator</ti> +<ti>The nickname of the coordinator assigned to the bug, optional</ti> +<ti>koon</ti> +</tr> +<tr> +<ti>KEYWORD</ti> +<ti>The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC</ti> +<ti>CLASSIFIED</ti> +</tr> +<tr> +<ti>CRD</ti> +<ti>The coordinated release date for the bugs disclosure. If no time is given, assume 14:00 UTC.</ti> +<ti>2009-01-06 18:00 UTC</ti> +</tr> + +</table> + +<p> +The following extra statuses are accepted in confidential bugs: +</p> + +<table> +<tr> +<th>Status</th> +<th>Description</th> +</tr> +<tr> +<ti>preebuild</ti> +<ti>Specific package maintainer has been called to prepare an ebuild which + must not be committed in the CVS tree, but attached to the bug</ti> +</tr> +<tr> +<ti>prestable</ti> +<ti>Specific arch testers has been called to test a not-yet-public ebuild</ti> +</tr> +</table> + +</body> +</section> +<section> +<title>Handling confidential bugs</title> +<body> + +<p> +Semi-public bugs should be handled as public bugs, except that no herd or arch +alias should be Cc-ed on the bug but rather specific developers. +</p> + +<p> +Confidential and classified bugs need extra care. The ebuild and files fixing +the vulnerability should NOT be committed to portage CVS, and no part of those +bugs should ever be discussed in public. Patches or portage overlay tarballs +can be attached to the bug, though. Testers will have to setup their own +overlay to test it. +The idea with those bugs is to prepare the ebuild and have it tested for the +coordinated release date, so that it can be released with all needed KEYWORDS +together with the GLSA at the same time the issue goes public. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>GLSA drafting with GLSAMaker</title> +<section> +<title>General rules</title> +<body> + +<p> +The GLSA should use the affected software name with proper capitalization, not +the Gentoo package name. For example, you should use "MySQL" and not "mysql". +Lowercase names should be used only if the software has an all-lowercase name +or if the software is identified by its command name ("traceroute"). +</p> + +<p> +You should not copy any part of any existing advisory, but you may use +them as sources of information for our GLSA. If you copy, for example a +software description, from a website, please use a citation and quotes. +</p> + +</body> +</section> +<section> +<title>Title, Synopsis, Keywords</title> +<body> + +<p> +The title must be short (< 60 characters in most cases) and have the application +name (not category) in front. It should allow to clearly identify the +vulnerability, without getting into any details. Version should be left out, +except in rare cases where it allows to identify the package more clearly. +Multiple affected packages should be separated by a comma. Examples include: +</p> + +<table> +<tr> +<ti>MySQL: Insecure temporary file creation</ti> +</tr> +<tr> +<ti>Exim: verify=header_syntax buffer overflow</ti> +</tr> +<tr> +<ti>Apache 1.3: Heap overflow in mod_redirect</ti> +</tr> +<tr> +<ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti> +</tr> +</table> + +<p> +Synopsis is a short (< 160 characters), but complete, description of the +vulnerability. People reading only the Synopsis should get a good idea what +the vulnerability is and what impact it has. Examples include: +</p> + +<table> +<tr> +<ti>Two MySQL utilities create temporary files with hardcoded paths, allowing +an attacker to use a symlink to trick MySQL into overwriting important +data.</ti> +</tr> +<tr> +<ti>Multiple vulnerabilities, including remotely exploitable buffer overflows, +have been found in code common to MPlayer and the xine library.</ti> +</tr> +</table> + +<p> +The GLSA keyword category is typically set to "Ebuild" and should contain the +name of the main software vulnerable (for example, "MySQL"). Other keyword +types include "Portage" (for portage bugs) and "Infrastructure" (for server +compromises). +</p> + +</body> +</section> +<section> +<title>Access, Severity</title> +<body> + +<p> +Access should be "Local" or "Remote". Local +vulnerabilities can be carried out only by a local user of the system. For +example it implies to run a specific executable to elevate privileges, or access +to a temporary directory to run a symlink attack. Remote vulnerabilities are +those that can be exploited by an attacker with or without an account on the +system. Remote vulnerabilities can either be active (exploiting a listening +server by sending malicious queries) or passive (enticing a user to connect +client software to a malicious server or to open malicious files). +</p> + +<p> +Severity is an indication of how deep the vulnerability is. It is defined in +the Vulnerability Treatment Policy, in the table "Evaluate the vulnerability +type". Note that it depends only on +the maximum risk, not on the commonality of the configuration option at risk. +A buffer overflow allowing arbitrary code execution in a rare client software, +only when it uses a specific configuration option, theoretically remains a "High" +severity. A denial of service on all configurations of Apache theoretically +remains a "Normal" severity. In rare cases the severity may be adjusted, when +several members of the Security Team agree, to a more relevant level. For +example, a vulnerability allowing defacement of web sites on Apache and all +configurations should probably be "High" rather than "Normal". +</p> + +</body> +</section> +<section> +<title>Unaffected, Vulnerable packages</title> +<body> + +<p> +This section provides information about versions of packages that are +unaffected or vulnerable to the vulnerability described in this advisory. +You should pay special attention to those numbers as they are one of the +few areas where mistakes imply an errata publication. +</p> + +<p> +There are the different fields composing an version entry. The package name +field must list the category and package name ("net-mail/exim"). Regarding +the "Architectures" field, you should put "*" in it when +the version description applies to all the arches marked in the ebuild. +You should use multiple entries for different arches if the version +description is different from arch to arch. +The "Auto" field must be set to true if the package is upgradeable +by emerge. For the version fields, there are multiple cases. +</p> + +<impo> +In this section (and only in this section), the architectures should be +written as they appear in the KEYWORDS (i.e. "x86", "amd64", "sparc"...), +and not in uppercase. +</impo> + +<p> +The simple case is when the vulnerability is present in all old versions, +and is fixed in all versions newer than a specific fix version. In this case, +you should use ">= first fixed version" as unaffected and "<= last +affected version" as vulnerable. You should double-check that there was no +ebuild between the last affected version and the first fixed version. When in +doubt, you should use ">= first fixed version" as unaffected and "< first +fix version" as vulnerable. +</p> + +<p> +A more complex case is when the vulnerability is present only in a few recent +versions. Let's take the example of a package where 1.2.8-r2 was not affected, +1.2.9, 1.2.9-r1 and 1.2.9-r2 were affected, and 1.2.10 is fixed. In this case +there are two possibilities: +</p> + +<table> +<tr> +<th>Unaffected</th> +<th>Vulnerable</th> +</tr> +<tr> +<ti>>=1.2.10</ti> +<ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti> +</tr> +<tr> +<ti><=1.2.8-r2 >=1.2.10</ti> +<ti><1.2.10</ti> +</tr> +</table> + +<p> +Finally, when the package has no fixed version, you should omit the +"Unaffected" entry for that package and set "Auto" to "no". +</p> + +<impo> +When the fix versions are complex, you should double-check that the XML and +TXT versions of the GLSA list your versions correctly. +</impo> + +</body> +</section> +<section> +<title>Background, Description, Impact</title> +<body> + +<p> +The Background section gives information about the package at risk. It describes +briefly what it is and gives any information that is helpful in understanding +the part of the package vulnerable. The Background section should be shorter +than the Description section or the Impact section. Good examples include: +</p> + +<table> +<tr> +<ti>The K Desktop Environment (KDE) is a powerful Free Software graphical +desktop environment. KDE makes use of URI handlers to trigger various +programs when specific URLs are received.</ti> +</tr> +<tr> +<ti>CVS (Concurrent Versions System) is an open-source network-transparent +version control system. It contains both a client utility and a server.</ti> +</tr> +<tr> +<ti>Metamail is a program that decodes MIME encoded mail. It is therefore +often automatically called when an email is received or read.</ti> +</tr> +</table> + +<p> +The Description section details what the vulnerability is, without telling what +happens when it is exploited. It should be understandable by people without +too much security background. Sometimes there is no information about the +vulnerability at all, in which cases you should let the description short. +Good examples include: +</p> + +<table> +<tr> +<ti>The telnet URI handler in Opera does not check for leading '-' characters +in the host name. Consequently, a maliciously-crafted telnet:// link may be +able to pass options to the telnet program itself. One example would be +"telnet://-nMyFile" If MyFile exists in the user's home directory and the +user clicking on the link has write permissions to it, the contents of the +file will be overwritten with the output of the telnet trace information. If +MyFile does not exist, the file will be created in the user's home +directory.</ti> +</tr> +<tr> +<ti>The MySQL bug reporting utility (mysqlbug) creates a temporary file to +log bug reports to. A malicious local user with write access to the /tmp +directory could create a symbolic link of the name mysqlbug-N pointing to a +protected file, such as /etc/passwd, such that when mysqlbug creates the Nth +log file, it would end up overwriting the target file. A similar +vulnerability exists with the mysql_multi utility, which creates a temporary +file called mysql_multi.log.</ti> +</tr> +<tr> +<ti>Multiple vulnerabilities have been found and fixed in the RTSP handling +code common to recent versions of these two packages. These vulnerabilities +include several remotely exploitable buffer overflows.</ti> +</tr> +</table> + +<p> +The Impact section describes the global impact of the vulnerabilities described +in the Description section, when exploited. It should focus on the maximum risk. +Good examples: +</p> + +<table> +<tr> +<ti>A remote attacker, posing as a RTSP stream server, can execute arbitrary +code with the rights of the user of the software playing the stream (MPlayer +or any player using xine-lib). Another attacker may entice a user to use a +maliciously crafted URL or playlist to achieve the same results.</ti> +</tr> +<tr> +<ti>This vulnerability has two possible impacts. First, it may create new files in +the user's home directory. Second, and far more serious, it may overwrite +existing files that the user has write permissions to. An attacker with some +knowledge of a user's home directory might be able to destroy important +files stored within.</ti> +</tr> +</table> + +</body> +</section> +<section> +<title>Workaround, Resolution</title> +<body> + +<p> +The workaround describes if there is any simple way (other than upgrading +to the fix version) of avoiding to be vulnerable. Good examples include: +</p> + +<table> +<tr> +<ti>For a temporary workaround, providing you do not require Kerberos 4 +support, you may turn off Kerberos 4 kadmin by running kadmind with the +--no-kerberos4 option.</ti> +</tr> +<tr> +<ti>There is no known workaround at this time.</ti> +</tr> +</table> + +<p> +The Resolution section explains in human-readable terms what you have to do +to be fully protected against the vulnerability. This section must look like +this: +</p> + +<pre caption="Resolution example"> +All Heimdal users should upgrade to the latest stable version: +<code> +# emerge --sync +# emerge --ask --oneshot --verbose ">=app-crypt/heimdal-0.6.2" +</pre> + +<p> +If there are multiple architectures, it should look like this: +</p> + +<pre caption="Multiple arch example"> +OpenOffice.org users on the SPARC architecture should: +<code> +# emerge --sync +# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.1.0-r3" +</code> +</p> +<p> +OpenOffice.org users on the PPC architecture should: +</p> +<code> +# emerge --sync +# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.0.3-r1" +</pre> + +<p> +If the GLSA is about a shared library, you should include the following +paragraph at the end of the Resolution section to warn about the +necessity to rebuild linked executables: +</p> + +<table> +<tr> +<ti>Packages which depend on this library may need to be recompiled. +Tools such as revdep-rebuild may assist in identifying some of these +packages.</ti> +</tr> +</table> + +</body> +</section> +<section> +<title>References</title> +<body> + +<p> +The References section should provide links to reference information about +the vulnerability. When a CVE number (CVE-XXXX-XXX) is available, it should +be provided (with the complete CVE number in "Title"). You can also link an +upstream developer advisory and/or +announce email, when available. You should avoid links to other distribution +advisories or non-official advisories from separate entities. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>GLSA publication</title> +<section> +<title>Peer reviewing</title> +<body> + +<p> +When the draft is finished, it must be submitted to the review of other members +of the Security Team, by calling for a review on the #gentoo-security channel. +The final version (after all corrections are made) must be approved by two +Security Team members before being committed and sent out. +</p> + +<p> +When reviewing a GLSA draft carefully check the correctness of the +following things: +</p> + +<ul> +<li>Affected/unaffected versions (Check ChangeLog that versions are +correct and make sure that there is no version not included by either +affected or unaffected).</li> +<li>Title correctness.</li> +<li>Severity and Access (Don't just rely on the bug rating and for +"Local" access a local account is needed otherwise it is "Remote").</li> +<li>Finally do a sanity check: Is this a real vulnerability and not +just a bug (like the Samba and Shadow non-vulnerabilities).</li> +</ul> +<p> +When the draft is approved, it must be assigned an official GLSA number. This +is done by calling the "Move" function in GLSAMaker to move the draft from the +pool to the official area. +</p> + +</body> +</section> +<section> +<title>GLSA XML commit</title> +<body> + +<p> +You need to commit the GLSA XML to the Gentoo CVS tree so that it automagically +appears in the RDF feed, the GLSA list, and the portage updates. You should +first update your GLSA directory in the gentoo CVS repository tree: +</p> + +<pre caption="Update CVS tree"> +you@home you $ <i>cd gentoo_cvs</i> +you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i> +</pre> + +<p> +Then you should click <c>Fetch</c> on the GLSA to download the XML version, +and save it into your local gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/ +directory. Then you should add and commit the XML file: +</p> + +<pre caption="Commit the GLSA"> +you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i> +you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i> +you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i> +</pre> + +</body> +</section> +<section> +<title>E-mail announcement</title> +<body> + +<warn> +Whenever you use a new setup (software or machine) to post a GLSA announcement, +you should get your setup checked by sending a test email to another member of +the Security Team. +</warn> + +<p> +Click on the Txt download to have a text version of the GLSA. Check that the +affected/unaffected section looks good, then prepare an email with the +following rules: +</p> + +<ul> +<li><b>From</b> and <b>Return-Path</b> must be set to yourname@gentoo.org</li> +<li><b>To</b> and <b>Cc</b> should be set according to policy</li> +<li><b>Subject</b> must be "[ GLSA XXXXYY-ZZ ] Your vulnerability here" + (you should copy/paste from the title in the Txt file)</li> +<li>the body of the mail should be the content of the Txt file, from the +"Gentoo Linux Security Advisory" header to the end of the file</li> +<li>email must be signed by the GPG key for your yourname@gentoo.org address</li> +</ul> + +<note> +You will receive a return email from gentoo-announce telling it requires +moderation. Just reply to it and the announce email will get through. +</note> + +</body> +</section> +<section> +<title>Bug closing</title> +<body> + +<p> +You should check that the email got through to gentoo-announce, then you can +close the related bug(s), by setting their status to <b>RESOLVED/FIXED</b>, +with a comment pointing to the GLSA number. +</p> + +</body> +</section> +<section> +<title>Errata/Update publication</title> +<body> + +<p> +An erratum is published when we made a mistake otherwise it is an +update. When policy warrants a republication these guidelines should be followed: +</p> + +<ul> +<li>Revision should be correctly set in XML. This means that revision might need to +be manually corrected in GLSAMaker data directory, if you do multiple +changes using GLSAMaker ( ie. <revised>September +10, 2004: 02</revised>)</li> +<li>If there is no vulnerability no affected packages should be listed +in the XML</li> +<li>Title can change ( ie. GLSA 200409-14 for Samba and GLSA 200411-01 for ppp) +</li> +<li>Not all Errata need republication. Policy details when +republication is needed.</li> +<li>For the text version GLSAmaker can add the relevant information to +updates and erratas. Manually follow the instructions provided by +GLSAmaker.</li> +<li>Text version must contain an Errata or Update section (example shown below) and AFTER THAT only the +sections changed (XML version does not have extra sections)</li> +</ul> + +<table> +<tr> +<ti>This advisory incorrectly described ppp as being vulnerable to a +remote denial of service. After further verifications, it appears that a +remote user can only deny service to himself, so this bug does not induce any +security issue at all. The corrected sections appear below.</ti> +</tr> +</table> + +<p> + For two complete errata email examples see <uri + link="http://archives.gentoo.org/gentoo-announce/msg_59c7b7e81a7acacb1cbde24ab708f07a.xml">ERRATA: + [ GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> + (where there were no real vulnerability) and <uri + link="http://archives.gentoo.org/gentoo-announce/msg_e75f5d493fea7c6f718a850abd59598a.xml">ERRATA: [ GLSA 200801-09 ] + X.Org X server and Xfont library: Multiple vulnerabilities</uri> (where the problem was not correctly fixed in the + initial version). For an update example see <uri + link="http://archives.gentoo.org/gentoo-announce/msg_0f18bca197c64b634db757a18d2ae492.xml">UPDATE: + [ GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included + xpdf</uri> (where the fix introduced another vulnerability). +</p> + +<p> +Otherwise normal GLSA publication guidelines should be followed. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>GLSA Coordinators Tools</title> +<section> +<title>Information gathering</title> +<body> + +<ul> +<li><uri link="http://dev.gentoo.org/~vorlon/pv/">packageview</uri> + is a tool that will open packages.gentoo.org and Gentoo ViewCVS + at the right place for a given category and package name. It helps to + determine what keywords are needed and to track changes to a package.</li> +</ul> + +</body> +</section> +<section> +<title>GLSA publication helpers</title> +<body> + +<ul> +<li><uri link="http://dev.gentoo.org/~falco/glsacommit.txt">glsacommit</uri> + is a bash function handling GLSA commit. It features ssh-agent keyadding, + glsa-check conformity doublecheck and has "Are you sure" functions. Edit + it to suit your needs and directory locations.</li> +</ul> + +</body> +</section> +<section> +<title>Security Subversion repository</title> +<body> + +<ul> +<li>The <uri link="http://overlays.gentoo.org/proj/security/timeline">Security Subversion repository</uri> +contains several tools to collaboratively assess whether we are affected by new CVE identifiers, and +tools to determine target keywords. Most tools directly interact with Bugzilla, making manual +copy-pasting unnecessary. +</li> +</ul> + +</body> +</section> +</chapter> +</guide> |