~ubuntu-branches/ubuntu/raring/findutils/raring

« back to all changes in this revision

Viewing changes to doc/find.texi

  • Committer: Bazaar Package Importer
  • Author(s): Andreas Metzler
  • Date: 2007-06-02 09:55:27 UTC
  • mfrom: (1.1.8 upstream)
  • Revision ID: james.westby@ubuntu.com-20070602095527-2lkz5t7wsm0yd2xy
Tags: 4.2.31-1
* Undo workaround for savannah #19550, since it is a glibc bug.
* New upstream bugfix release:
  - Fixes locate heap buffer overflow when using databases in old format.
    (CVE-2007-2452) Closes: #426862
  - make clean does not delete regexprops.texi if cross-building.
    (Closes: #420190)
  - [-version] instead of [--version] in locate --help. (Closes: #412459)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1901
1901
command lines will not be invoked (this prevents possible infinite
1902
1902
loops).
1903
1903
 
 
1904
At first sight, it looks like the list of filenames to be processed
 
1905
can only be at the end of the command line, and that this might be a
 
1906
problem for some comamnds (@code{cp} and @code{rsync} for example).
 
1907
 
 
1908
However, there is a slightly obscure but powerful workarouund for this
 
1909
problem which takes advantage of the behaviour of @code{sh -c}:-
 
1910
 
 
1911
@example
 
1912
find startpoint -tests @dots{} -exec sh -c 'scp "$@@" remote:/dest' sh @{@} + 
 
1913
@end example
 
1914
 
 
1915
In the example above, the filenames we want to work on need to occur
 
1916
on the @code{scp} command line before the name of the destination.  We
 
1917
use the shell to invoke the command @code{scp "$@@" remote:/dest} and
 
1918
the shell expands @code{"$@@"} to the list of filenames we want to
 
1919
process.
 
1920
 
1904
1921
Another, but less secure, way to run a command on more than one file
1905
1922
at once, is to use the @code{xargs} command, which is invoked like
1906
1923
this:
2503
2520
programs and earlier releases of the GNU ones.  @code{updatedb}
2504
2521
produces this format if given the @samp{--old-format} option.
2505
2522
 
 
2523
All versions of GNU @code{locate} prior to 4.2.31 fail to correctly
 
2524
handle very long file names, possibly leading to security problems
 
2525
relating to a heap buffer overrun.  @xref{Security Considerations for
 
2526
locate}, for a detailed explanation.
 
2527
 
2506
2528
@code{updatedb} runs programs called @code{bigram} and @code{code} to
2507
2529
produce old-format databases.  The old format differs from the new one
2508
2530
in the following ways.  Instead of each entry starting with an
2941
2963
this option means that @code{locate} will not be able to properly
2942
2964
handle non-ASCII characters in file names (that is, file names
2943
2965
containing characters which have the eighth bit set, such as many of
2944
 
the characters from the ISO-8859-1 character set).
 
2966
the characters from the ISO-8859-1 character set).  Versions of
 
2967
@code{locate} prior to 4.2.31 fail to correctly handle long filenames
 
2968
in old-format databases.
2945
2969
@item --help
2946
2970
Print a summary of the command line usage and exit.
2947
2971
@item --version
4364
4388
@node Security Considerations for locate
4365
4389
@section Security Considerations for @code{locate}
4366
4390
 
 
4391
@subsection Race Conditions
4367
4392
It is fairly unusual for the output of @code{locate} to be fed into
4368
4393
another command.  However, if this were to be done, this would raise
4369
 
the same set of security issues as the use of @samp{find @dots{} -print}.
4370
 
Although the problems relating to whitespace in file names can be
4371
 
resolved by using @code{locate}'s @samp{-0} option, this still leaves
4372
 
the race condition problems associated with @samp{find @dots{} -print0}.
4373
 
There is no way to avoid these problems in the case of @code{locate}.
 
4394
the same set of security issues as the use of @samp{find @dots{}
 
4395
-print}.  Although the problems relating to whitespace in file names
 
4396
can be resolved by the @samp{-0} option of @code{locate}, this still
 
4397
leaves the race condition problems associated with @samp{find @dots{}
 
4398
-print0}.  There is no way to avoid these problems in the case of
 
4399
@code{locate}.
 
4400
 
 
4401
@subsection Long File Name Bugs with Old-Format Databases
 
4402
All versions of @code{locate} prior to 4.2.31 have a bug in the way
 
4403
that old-format databases are read.  They read file names into a
 
4404
fixed-length 1026 byte buffer, allocated on the heap.  This buffer is
 
4405
not extended if file names are too long to fit into the buffer.  No
 
4406
range checking on the length of the filename is performed.  This could
 
4407
in theory lead to a privilege escalation attack.  Findutils versions
 
4408
4.3.0 to 4.3.6 are also affected.
 
4409
 
 
4410
On systems using the old database format and affected versions of
 
4411
@code{locate}, carefully-chosen long file names could in theory allow
 
4412
malicious users to run code of their choice as any user invoking
 
4413
locate.
 
4414
 
 
4415
If remote users can choose the names of files stored on your system,
 
4416
and these files are indexed by @code{updatedb}, this may be a remote
 
4417
security vulnerability.  Findutils version 4.2.31 fixes this problem.
 
4418
The @code{updatedb}, @code{bigram} and @code{code} programs do no
 
4419
appear to be affected.
 
4420
 
 
4421
If you are also using GNU coreutils, you can use the following command
 
4422
to determine the length of the longest file name on a given system:
 
4423
 
 
4424
@example
 
4425
find / -print0 | tr -c '\0' 'x' | tr '\0' '\n' | wc -L
 
4426
@end example
 
4427
 
 
4428
Although this problem is significant, the old database format is not
 
4429
the default, and use of the old database format is not common.  Most
 
4430
installations and most users will not be affected by this problem.  
 
4431
 
4374
4432
 
4375
4433
@node Security Summary
4376
4434
@section Summary