[Findutils-patches] [PATCH] Added find-maint.texi sections Bugs and Distributions.

[James Youngman]

2007-06-25  James Youngman  <address@hidden>

        * doc/find-maint.texi: Added sections "Bugs" and "Distributions".
        Provided some initial text for "Security" and "Making Releases".

Signed-off-by: James Youngman <address@hidden>
---
 doc/find-maint.texi |  436 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 433 insertions(+), 3 deletions(-)

diff --git a/doc/find-maint.texi b/doc/find-maint.texi
index 4cb80b9..a438620 100644
--- a/doc/find-maint.texi
+++ b/doc/find-maint.texi
@@ -62,6 +62,8 @@ Free Documentation License''.
 * Using the GNU Portability Library::
 * Documentation::
 * Testing::
+* Bugs::
+* Distributions::
 * Internationalisation::
 * Security::
 * Making Releases::
@@ -330,7 +332,7 @@ documentation.
 
 @section User Documentation
 User-oriented documentation such as
address@hidden,,Introduction,find,The Findutils manual} and the
address@hidden,,Introduction,find,The Findutils manual} and the
 manual pages for the various findutils programs are the primary
 documentation.  
 
@@ -390,6 +392,70 @@ the test suite, and the functions defined in the 
findutils-specific
 DejaGnu configuration.  Where appropriate references will be made to
 the DejaGnu documentation.
 
address@hidden Bugs
address@hidden Bugs
+
+Bugs are logged in the Savannah bug tracker
address@hidden://savannah.gnu.org/bugs/?group=findutils}.  The tracker
+offers several fields but their use is largely obvious.  The
+life-cycle of a bug is like this:
+
+
address@hidden @asis
address@hidden Open
+Someone, usually a maintainer, a distribution maintainer or a user,
+creates a bug by filling in the form.   They fill in field values as
+they see fit.  This will generate an email to
address@hidden@@gnu.org}.  
+
address@hidden Triage
+The bug hangs around with @samp{Status=None} until someone begins to
+work on it.  At that point they set the ``Assigned To'' field and will
+sometimes set the status to @samp{In Progress}, especially if the bug
+will take a while to fix.
+
address@hidden Non-bugs
+Quite a lot of reports are not actually bugs; for these the usual
+procedure is to explain why the problem is not a bug, set the status
+to @samp{Invalid} and close the bug.   Make sure you set the
address@hidden to} field to yourself before closing the bug.
+
address@hidden Fixing
+When you commit a bugfix into CVS (or in the case of a contributed
+patch, commit the change), mark the bug as @samp{Fixed}.  Make sure
+you include a new test case where this is relevant.  If you can figure
+out which releases are affected, please also set the @samp{Release}
+field to the earliest release which is affected by the bug.
+Indicate which source branch the fix is included in (for example,
+4.2.x or 4.3.x).  Don't close the bug yet.
+
address@hidden Release
+When a release is made which includes the bug fix, make sure the bug
+is listed in the NEWS file.  Once the release is made, fill in the
address@hidden Release} field and close the bug.
address@hidden table
+
+
address@hidden Distributions
address@hidden Distributions
+Almost all GNU/Linux distributions include findutils, but only some of
+them have a package maintainer who is a member of the mailing list.
+Distributions don't often feed back patches to the
address@hidden@@gnu.org} list, but on the other hand many of
+their patches relate only to standards for file locations and so
+forth, and are therefore distirbution specific.  On an irregular basis
+I check the current patches being used by one or two distributions,
+but the total number of GNU/Linux distributions is large enough that
+we could not hope to cover them all.
+
+Often, bugs are raised against a distribution's bug tracker instead of
+GNU's.    Periodically (about every six months) I take a look at some
+of the more accessible bug trackers to indicate which bugs have been
+fixed upstream.  
+
+Many distributions include both findutils and the slocate package,
+which provides a replacement @code{locate}.  
+
 
 @node Internationalisation
 @chapter Internationalisation
@@ -407,12 +473,376 @@ See @ref{Security Considerations, ,Security 
Considerations,find,The
 Findutils manual}, for a full description of the findutils approach to
 security considerations and discussion of particular tools.
 
+If someone reports a security bug publicly, we should fix this as
+rapidly as possible.  If necessary, this can mean issuing a fixed
+release containing just the one bugfix.  We try to avoid issuing
+releases which include both significant security fixes and functional
+changes.  
+
+Where someone reports a security problem privately, we generally try
+to construct and test a patch without checking the intermediate code
+in.  Once everything has been tested, this allows us to commit a patch
+and immediately make a release.   The advantage of doing things this
+way is that we avoid situations where people watching for CVS commits
+can figure out and exploit a security problem before a fixed release
+is available. 
+
+If the security problem is serious, send an alert to
address@hidden@@lst.de}.  The members of the list include most
+GNU/Linux distributions.  The point of doing this is to allow them to
+prepare to release your security fix to their customers, once the fix
+becomes available.    Here is an example alert:-
+
address@hidden
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+GNU findutils heap buffer overrun (potential privilege escalation)
+
+$Revision: 1.5 $; $Date: 2007/05/28 21:15:25 $
+
+
+I. BACKGROUND
+=============
+
+GNU findutils is a set of programs which search for files on Unix-like
+systems.  It is maintained by the GNU Project of the Free Software
+Foundation.  For more information, see
+http://www.gnu.org/software/findutils.
+
+
+II. DESCRIPTION
+===============
+
+When GNU locate reads filenames from an old-format locate database,
+they are read into a fixed-length buffer allocated on the heap.
+Filenames longer than the 1026-byte buffer can cause a buffer overrun.
+The overrunning data can be chosen by any person able to control the
+names of filenames created on the local system.  This will normally
+include all local users, but in many cases also remote users (for
+example in the case of FTP servers allowing uploads).
+
+III. ANALYSIS
+=============
+
+Findutils supports three different formats of locate database, its
+native format "LOCATE02", the slocate variant of LOCATE02, and a
+traditional ("old") format that locate uses on other Unix systems.
+
+When locate reads filenames from a LOCATE02 database (the default
+format), the buffer into which data is read is automatically extended
+to accomodate the length of the filenames.
+
+This automatic buffer extension does not happen for old-format
+databases.  Instead a 1026-byte buffer is used.  When a longer
+pathname appears in the locate database, the end of this buffer is
+overrun.  The buffer is allocated on the heap (not the stack).
+
+If the locate database is in the default LOCATE02 format, the locate
+program does perform automatic buffer extension, and the program is
+not vulnerable to this problem.  The software used to build the
+old-format locate database is not itself vulnerable to the same
+attack.
+
+Most installations of GNU findutils do not use the old database
+format, and so will not be vulnerable.
+
+
+IV. DETECTION
+=============
+
+Software
+- --------
+All existing releases of findutils are affected.
+
+
+Installations
+- -------------
+
+To discover the ongest path name on a given system, you can use the
+following command (requires GNU findutils and GNU coreutils):
+
+find / -print0 | tr -c '\0' 'x' | tr '\0' '\n' | wc -L
+
+
+V. EXAMPLE
+==========
+
+This section includes a shell script which determines which of a list
+of locate binaries is vulnerable to the problem.  The shell script has
+been tested only on glibc based systems having a mktemp binary.
+
+NOTE: This script deliberately overruns the buffer in order to
+determine if a binary is affected.  Therefore running it on your
+system may have undesirable effects.  We recommend that you read the
+script before running it.
+
+#! /bin/sh
+set +m
+if vanilla_db="$(mktemp nicedb.XXXXXX)" ; then
+    if updatedb --prunepaths="" --old-format --localpaths="/tmp" \
+       --output="address@hidden@}" ; then
+       true
+    else
+       rm -f "address@hidden@}"
+       vanilla_db=""
+       echo "Failed to create old-format locate database; skipping the sanity 
checks" >&2
+    fi
+fi
+
+make_overrun_db() @{
+    # Start with a valid database
+    cat "address@hidden@}"
+    # Make the final entry really long
+    dd if=/dev/zero  bs=1 count=1500 2>/dev/null | tr '\000' 'x'
address@hidden
+
+
+
+ulimit -c 0
+
+usage() @{ echo "usage: $0 binary [binary...]" >&2; exit $1; @}
+[ $# -eq 0 ] && usage 1
+
+bad=""
+good=""
+ugly=""
+if dbfile="$(mktemp nasty.XXXXXX)"
+then
+    make_overrun_db > "$dbfile"
+    for locate ; do
+      ver="$locate = $("$locate"  --version | head -1)"
+      if [ -z "$vanilla_db" ] || "$locate" -d "$vanilla_db" "" >/dev/null ; 
then
+         "$locate" -d "$dbfile" "" >/dev/null
+         if [ $? -gt 128 ] ; then
+             bad="$bad
+vulnerable: $ver"
+         else
+             good="$good
+good: $ver"
+         fi
+       else
+         # the regular locate failed
+         ugly="$ugly 
+buggy, may or may not be vulnerable: $ver"
+       fi
+    done
+    rm -f "address@hidden@}" "address@hidden@}"
+    # good: unaffected.  bad: affected (vulnerable).  
+    # ugly: doesn't even work for a normal old-format database.
+    echo "$good"
+    echo "$bad"
+    echo "$ugly"
+else
+  exit 1
+fi
+
+
+
+
+
+VI. VENDOR RESPONSE
+===================
+
+The GNU project discovered the problem while 'locate' was being worked
+on; this is the first public announcement of the problem.
+
+The GNU findutils mantainer has issued a patch as p[art of this
+announcement.  The patch appears below.
+
+A source release of findutils-4.2.31 will be issued on 2007-05-30.
+That release will of course include the patch.  The patch will be
+committed to the public CVS repository at the same time.  Public
+announcements of the release, including a description of the bug, will
+be made at the same time as the release.
+
+A release of findutils-4.3.x will follow and will also include the
+patch.
+
+
+VII. PATCH
+==========
+
+This patch should apply to findutils-4.2.23 and later.
+Findutils-4.2.23 was released almost two years ago.
+
+Index: locate/locate.c
+===================================================================
+RCS file: /cvsroot/findutils/findutils/locate/locate.c,v
+retrieving revision 1.58.2.2
+diff -u -p -r1.58.2.2 locate.c
+- --- locate/locate.c  22 Apr 2007 16:57:42 -0000      1.58.2.2
++++ locate/locate.c    28 May 2007 10:18:16 -0000
+@@@@ -124,9 +124,9 @@@@ extern int errno;
+ 
+ #include "locatedb.h"
+ #include <getline.h>
+- -#include "../gnulib/lib/xalloc.h"
+- -#include "../gnulib/lib/error.h"
+- -#include "../gnulib/lib/human.h"
++#include "xalloc.h"
++#include "error.h"
++#include "human.h"
+ #include "dirname.h"
+ #include "closeout.h"
+ #include "nextelem.h"
+@@@@ -468,10 +468,36 @@@@ visit_justprint_unquoted(struct process_
+   return VISIT_CONTINUE;
+ @}
+ 
++static void
++toolong (struct process_data *procdata)
address@hidden
++  error (1, 0,
++       _("locate database %s contains a "
++         "filename longer than locate can handle"),
++       procdata->dbfile);
address@hidden
++
++static void
++extend (struct process_data *procdata, size_t siz1, size_t siz2)
address@hidden
++  /* Figure out if the addition operation is safe before performing it. */
++  if (SIZE_MAX - siz1 < siz2)
++    @{
++      toolong (procdata);
++    @}
++  else if (procdata->pathsize < (siz1+siz2))
++    @{
++      procdata->pathsize = siz1+siz2;
++      procdata->original_filename = x2nrealloc (procdata->original_filename,
++                                              &procdata->pathsize,
++                                              1);
++    @}
address@hidden
++
+ static int
+ visit_old_format(struct process_data *procdata, void *context)
+ @{
+- -  register char *s;
++  register size_t i;
+   (void) context;
+ 
+   /* Get the offset in the path where this path info starts.  */
+@@@@ -479,20 +505,35 @@@@ visit_old_format(struct process_data *pr
+     procdata->count += getw (procdata->fp) - LOCATEDB_OLD_OFFSET;
+   else
+     procdata->count += procdata->c - LOCATEDB_OLD_OFFSET;
++  assert(procdata->count > 0);
+ 
+- -  /* Overlay the old path with the remainder of the new.  */
+- -  for (s = procdata->original_filename + procdata->count;
++  /* Overlay the old path with the remainder of the new.  Read 
++   * more data until we get to the next filename.
++   */
++  for (i=procdata->count;
+        (procdata->c = getc (procdata->fp)) > LOCATEDB_OLD_ESCAPE;)
+- -    if (procdata->c < 0200)
+- -      *s++ = procdata->c;           /* An ordinary character.  */
+- -    else
+- -      @{
+- -    /* Bigram markers have the high bit set. */
+- -    procdata->c &= 0177;
+- -    *s++ = procdata->bigram1[procdata->c];
+- -    *s++ = procdata->bigram2[procdata->c];
+- -      @}
+- -  *s-- = '\0';
++    @{
++      if (procdata->c < 0200)
++      @{
++        /* An ordinary character. */    
++        extend (procdata, i, 1u);
++        procdata->original_filename[i++] = procdata->c;
++      @}
++      else
++      @{
++        /* Bigram markers have the high bit set. */
++        extend (procdata, i, 2u);
++        procdata->c &= 0177;
++        procdata->original_filename[i++] = procdata->bigram1[procdata->c];
++        procdata->original_filename[i++] = procdata->bigram2[procdata->c];
++      @}
++    @}
++
++  /* Consider the case where we executed the loop body zero times; we
++   * still need space for the terminating null byte. 
++   */
++  extend (procdata, i, 1u);
++  procdata->original_filename[i] = 0;
+ 
+   procdata->munged_filename = procdata->original_filename;
+   
+
+
+
+VIII. THANKS
+============
+
+Thanks to Rob Holland <rob@@inversepath.com> and Tavis Ormandy.
+
+
+VIII. CVE INFORMATION
+=====================
+
+No CVE candidate number has yet been assigned for this vulnerability.
+If someone provides one, I will include it in the public announcement
+and change logs.
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQFGW0sucqCfqxMUHDYRAntVAKCIt54u8If+gpRtdwf+OHH5F+UUbACeNFWV
+KQ8qLDri26ScoEXXXQn08QA=
+=olFi
+-----END PGP SIGNATURE-----
address@hidden example
+
+
+Once a fixed release is available, announce the new release using the
+normal channels.  Any CVE number assigned for the problem should be
+included in the @file{ChangeLog} and @file{NEWS} entries. See
address@hidden://cve.mitre.org/} for an explanation of CVE numbers.
+
+
 
 @node Making Releases
 @chapter Making Releases
-This section will explain how to make a findutils release.
+This section will explain how to make a findutils release.   For the
+time being here is a terse description of the main steps:
+
address@hidden
address@hidden Commit changes; make sure your working directory has no
+uncomitted changes.
address@hidden Test; make sure that all changes ou have made have tests, and
+that the tests pass.  Verify this with @code{make distcheck}.
address@hidden Bugs; make sure all Savannah bug entries fixed in this release
+are fixed.
address@hidden NEWS; make sure that the NEWS and configure.in file are updated
+with the new release number (and checked in).
address@hidden Build the release tarball; do this with @code{make distcheck}.
+Copy the tarball somewhere safe.
address@hidden Tag the release; findutils releases are tagged in CVS as
+FINDUTILS_x_y_z-1.  For example, the tag for findutils release 4.3.8
+is FINDUTILS_4_3_8-1.
address@hidden Prepare the upload and upload it; see the
address@hidden FTP Uploads, ,Automated FTP
+Uploads, maintain, Information for Maintainers of GNU Software}
+for detailed upload instructions.
address@hidden Make a release announcement; include an extract from the NEWS
+file which explains what's changed.  Announcements for test releases
+should just go to @email{bug-findutils@@gnu.org}.  Announcements for
+stable releases should go to @email{info-gnu@@gnu.org} as well.
address@hidden Bump the release numbers in CVS; edit the @file{configure.in}
+and @file{NEWS} files to advance the release numbers.   For example,
+if you have just released @samp{4.6.2}, bump the release number to
address@hidden  The point of the @samp{-CVS} suffix here is that a
+findutils binary built from CVS will bear a release number indicating
+it's not built from the the ``official'' source release.
address@hidden Close bugs; any bugs recorded on Savannah which were fixed in 
this
+release should now be marked as closed.   Update the @samp{Fixed
+Release} field of these bugs appropriately and make sure the
address@hidden to} field is populated.
address@hidden enumerate
 
address@hidden fn
 
 @bye
 
-- 
1.5.2.1