[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Findutils-patches] [PATCH] Added find-maint.texi sections Bugs and Dist
From: |
James Youngman |
Subject: |
[Findutils-patches] [PATCH] Added find-maint.texi sections Bugs and Distributions. |
Date: |
Mon, 25 Jun 2007 00:36:05 +0100 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Findutils-patches] [PATCH] Added find-maint.texi sections Bugs and Distributions.,
James Youngman <=