Bugzilla Bug 144869

cscope Multiple Vulnerabilities
-------------------------------


Summary
-------

Multiple vulnerabilities have been discovered in cscope that allow
for the execution of arbitrary code.


Background
----------

From cscope.sourceforge.net:
 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
 of code!


Impact
------

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.


Workaround
----------

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.


Discussion
----------

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
ways:
- 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
result
in 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
  $ cscope


* 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
  $ cscope


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
  $ cscope

(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'`

Upstream patches @

http://sourceforge.net/mailarchive/forum.php?thread_id=30266760&forum_id=33500
http://sourceforge.net/mailarchive/forum.php?thread_id=30266761&forum_id=33500

Matthew, would you be so kind so as to bump our cscope with these ?

mkennedy any news on this one?

I don't have a machine to use for the week.

-dev mailed.

No answer. Security I suggest a mask, comments?

I would mask it, after all -dev was warned about it

I just added a snapshot from CVS which will include the fix to this.

this was _really_ close to being masked

arches pls test and mark stable if possible

target KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc
x86 ~x86-fbsd"

this time even adding arches to CC ;-)

In x86:

Compiles and works nice.

Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3,
2.6.17-gentoo-r8 i686)
=================================================================
System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) Processor
Gentoo Base System version 1.12.5
Last Sync: Mon, 02 Oct 2006 19:50:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: [Not Present]
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r4
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-tbird -mtune=athlon-tbird  -O2 -pipe
-fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=athlon-tbird -mtune=athlon-tbird  -O2 -pipe
-fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks metadata-transfer sandbox
sfperms strict"
GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ "
LINGUAS=""
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise"
SYNC="rsync://rsync.belnet.be/packages/gentoo-portage"
USE="x86 X bitmap-fonts bzip2 cairo cdr cli crypt dbus dlloader dri dvd dvdr
eds elibc_glibc emboss encode fam firefox fortran gif gpm gstreamer gtk hal
input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg
kernel_linux ldap libg++ mad mikmod mp3 mpeg ncurses nptl nptlonly ogg opengl
pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl
session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode
userland_GNU video_cards_vesa vorbis win32codecs xml xorg xv zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS

So are we talking about marking cscope-15.5.20060927 stable?  If so, how do
people feel about marking a cvs snapshot stable for their arches?

Brent raises a good question here.
I guess we should suspend stable marking until we have a comment from mkennedy
or vim/emacs.
What about an ebuild which just adds the needed patches?

We would be running into patch conflicts continuting on from -r6.  This means
recomputing the patches, and given that cscope was almost removed from the tree
due to lack of interest in this security bug, we definitely don't want to make
it harder to maintain.

CVS is not a fast moving target for cscope.  Most development in there seems to
be related to security vulnerabilities.

We can either make this CVS snapshot stable, or we can remove -r6 from portage,
leaving stable without a cscope until this CVS snapshot has had adequate
testing.  If you want to go with the former, you'll need to check for
regressions -- go through the ebuild ChangeLog and make sure the bugs solved
there are not reintroduced in the CVS snapshot.

(In reply to comment #13)
> or we can remove -r6 from portage

This would imply masking kscope and changing the vim ebuild accordingly. Even
Debian chose to package a snapshot

(In reply to comment #13)
> or we can remove -r6 from portage

This would imply masking kscope and changing the vim ebuild accordingly. Even
Debian chose to package a snapshot¹, btw..


[1]
http://ftp.debian.org/debian/pool/main/c/cscope/cscope_15.5+cvs20060902-2.diff.gz

Any progress here?

x86 done. Thanks for reminding.

sparc stable.

(In reply to comment #16)
> x86 done. Thanks for reminding.
> 

Mh, that was more intended to be something like "did someone decide, if we want
to stable a snapshot or not?" ... so ... we want to stable a snapshot?
mkennedy?

i just gave a couple of suggestions, but it looks like it's being decided per
arch

stable on alpha and amd64.

ppc64 stable

Stable on ppc.

On amd64 and ia64 (at least), "make cscope" in a kernel source tree segfaults
with (now stable) cscope-15.5.20060927.  It works fine with cscope-1.15-r6. 
Clearly this isn't ready for release.

You might want to file a bug then.  emerge --info, a back trace etc.

Stable on hppa.

(In reply to comment #24)
> You might want to file a bug then.  emerge --info, a back trace etc.

/me looks sheepish

Filed as bug 151503

Let's go for a GLSA. bug 151503 seems not very common.

GLSA 200610-08