Next: Security Summary, Previous: Security Considerations for xargs, Up: Security Considerations
locateIt is fairly unusual for the output of locate to be fed into
another command. However, if this were to be done, this would raise
the same set of security issues as the use of ‘find ... -print’.
Although the problems relating to whitespace in file names can be
resolved by using locate's ‘-0’ option, this still leaves
the race condition problems associated with ‘find ... -print0’.
There is no way to avoid these problems in the case of locate.
Old versions of locate have a bug in the way that old-format
databases are read. This bug affects the following versions of
locate:
The affected versions of locate read file names into a
fixed-length 1026 byte buffer, allocated on the heap. This buffer is
not extended if file names are too long to fit into the buffer. No
range checking on the length of the filename is performed. This could
in theory lead to a privilege escalation attack. Findutils versions
4.3.0 to 4.3.6 are also affected.
On systems using the old database format and affected versions of
locate, carefully-chosen long file names could in theory allow
malicious users to run code of their choice as any user invoking
locate.
If remote users can choose the names of files stored on your system,
and these files are indexed by updatedb, this may be a remote
security vulnerability. Findutils version 4.2.31 and findutils
version 4.3.7 include fixes for this problem. The updatedb,
bigram and code programs do no appear to be affected.
If you are also using GNU coreutils, you can use the following command to determine the length of the longest file name on a given system:
find / -print0 | tr -c '\0' 'x' | tr '\0' '\n' | wc -L
Although this problem is significant, the old database format is not the default, and use of the old database format is not common. Most installations and most users will not be affected by this problem.