Will Drewry of the Google Security Team discovered several minor buffer overflow
flaws in cscope. His advisory is below:
cscope Multiple Vulnerabilities
Multiple vulnerabilities have been discovered in cscope that allow
for the execution of arbitrary code.
cscope is a developer's tool for browsing source code. It has an impeccable
Unix pedigree, having been originally developed at Bell Labs back in the days
of the PDP-11. Cscope was part of the official AT&T Unix distribution for
many years, and has been used to manage projects involving 20 million lines
A successful exploit would resulting the execution of arbitrary code
immediately after executing cscope. In some environments, cscope may be
executed automatically on start up of the user's text editor or IDE.
When using cscope,
- ensure that there are no unexpected `cscope.files'.
- ensure that any source trees do not have full paths that exceed 250
characters or look particularly out of place.
- ensure that any source trees do not have directory or file names
with embedded newline or `$' characters.
Multiple exploitable stack buffer overflows have been found in cscope due to
the unchecked use of strcpy() and *scanf():
* Use of fscanf() and sscanf() without enforced field maximum widths during
file list parsing
This results in an exploitable condition which may be triggered in a number of
- specially crafted cscope.files may be placed in a shared working directory
- specially crafted directory and file names in a source tree, or archive.
In the first case, an attacker may leave a `cscope.files' file in a directory
where the victim is likely to run cscope. This is particularly dangerous
because some text editors will automatically execute it cscope on start-up.
In the second case, an attacker may modify a shared source tree or supply a
prepackaged source archive with specially crafted file and directory names. The
victim would then need to run cscope over a list of this source tree's files.
If the resulting list contained any specially crafted paths, and it would
resultin an overflow condition. As with the first case, some editors will
automatically generate this file list and execute cscope on it. This would
result in the attack occurring in the background, unbeknownst to the victim.
In both cases, the resulting file list will have a path to a file that exceeds
250 characters. E.g.,
$ bash -c 'D=$(ruby -e "print \"A\" * 255;"); for i in $(seq 1 15); do
mkdir $D; cd $D; touch A; done;'
$ find ./ -type f > cscope.files
* Multiple unchecked uses of strcpy() during path variable expansion
cscope allows users to specify limited arguments in addition to files in the
`cscope.files' file list. When using the `-I' option, the subsequent paths will
have variable expansion performed prior to use. The '~' character is
expanded to the caller's `HOME' environment variable, and any occurrence of the
`$' character followed by a string will be expanded to the value of that
particular environment variable. e.g., "-I $SHELL" may become "-I /bin/bash".
These cases result in two separate crash conditions due to the unchecked
use of strcpy().
Tilde expansion may result in a stack buffer overflow if and only if the
victim's `HOME' environment variable is changed to exceed the maximum allocated
space for expansion:
$ export HOME=$(ruby -e "print 'A'*2048")
$ echo "-I~/foo.c" > cscope.files
However, general environment variable expansion is much more dangerous. This
attack allows a similar attack to the *scanf() attacks which can be triggered
using similar mechanisms. A specially crafted file list will result in the
execution of arbitrary code. The difference is that maximum field width
checking does not mitigate this attack. The specially crafted directory and
file names may contain environment variable references which expand to much
longer strings than the environment variable's name.
Because of this, more knowledge of the victim's environment is required in
order to create an effective exploit. However, some assumptions can be made
about common environment variables, such as `SHELL' and `LS_COLORS', that
make this attack viable.
# This directory may exist in a given source tree:
$ mkdir '^J-I$LS_COLORS'
$ touch '^J-I$LS_COLORS/payload_here'
# The end user may run this to build a filelist
$ find ./ -type -f > cscope.files
(Note, ^J represents the key combination "Ctrl+j".)
* Unchecked use of strcpy() during command line argument parsing
This results in a command line based overflow attack. The impact of this
attack is minimal given that cscope is not normally run setuid, and the
attacker would need to have some control over the call to cscope. The overflow
occurs when cscope strcpy()s the `reffile` argument value over the statically
allocated stack buffer for `reffile'.
$ cscope -f `ruby -e 'print "A"*500'`
The patches (from upstream can be found here:
This links above does not seem to work any more with new SF.net site. New links:
[Cscope-cvs] CVS: cscope ChangeLog,1.158,1.159
[Cscope-cvs] CVS: cscope/src build.c, 1.11, 1.12 command.c, 1.31, 1.32 dir.c, 1.27, 1.28 display.c, 1.28, 1.29 edit.c, 1.5, 1.6 input.c, 1.14, 1.15 main.c, 1.40, 1.41 constants.h, 1.14, 1.15
This issue has been addressed in following products:
Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 3
Via RHSA-2009:1101 https://rhn.redhat.com/errata/RHSA-2009-1101.html