144869 2006-08-23 09:25 0000 dev-util/cscope Multiple Vulnerabilities (CVE-2006-4262) 2006-11-11 20:48:17 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203645 B2 [glsa] P2 normal --- 1 jaervosz@gentoo.org security@gentoo.org agriffis@gentoo.org ed@catmur.co.uk emacs@gentoo.org mips@gentoo.org mkennedy@gentoo.org tcort@gentoo.org vim@gentoo.org jaervosz@gentoo.org 2006-08-23 09:25:42 0000 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'` koon@gentoo.org 2006-08-23 12:03:19 0000 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 ? jaervosz@gentoo.org 2006-09-05 06:45:59 0000 mkennedy any news on this one? mkennedy@gentoo.org 2006-09-08 09:14:13 0000 I don't have a machine to use for the week. jaervosz@gentoo.org 2006-09-19 00:50:04 0000 -dev mailed. jaervosz@gentoo.org 2006-09-26 09:35:30 0000 No answer. Security I suggest a mask, comments? koon@gentoo.org 2006-09-27 12:58:16 0000 I would mask it, after all -dev was warned about it mkennedy@gentoo.org 2006-09-27 20:52:19 0000 I just added a snapshot from CVS which will include the fix to this. vorlon@gentoo.org 2006-09-29 04:35:04 0000 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" vorlon@gentoo.org 2006-10-03 07:37:59 0000 this time even adding arches to CC ;-) armin76@gentoo.org 2006-10-03 07:47:42 0000 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 ranger@gentoo.org 2006-10-03 09:13:26 0000 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? vorlon@gentoo.org 2006-10-03 09:19:29 0000 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? mkennedy@gentoo.org 2006-10-04 12:32:52 0000 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. carlo@gentoo.org 2006-10-07 05:17:03 0000 (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 carlo@gentoo.org 2006-10-07 05:17:03 0000 (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 dertobi123@gentoo.org 2006-10-10 08:13:35 0000 Any progress here? ticho@gentoo.org 2006-10-11 00:15:16 0000 x86 done. Thanks for reminding. gustavoz@gentoo.org 2006-10-11 11:17:21 0000 sparc stable. dertobi123@gentoo.org 2006-10-11 11:20:36 0000 (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? mkennedy@gentoo.org 2006-10-11 11:44:14 0000 i just gave a couple of suggestions, but it looks like it's being decided per arch tcort@gentoo.org 2006-10-14 11:13:59 0000 stable on alpha and amd64. corsair@gentoo.org 2006-10-14 12:24:15 0000 ppc64 stable hansmi@gentoo.org 2006-10-14 13:20:23 0000 Stable on ppc. agriffis@gentoo.org 2006-10-14 20:47:38 0000 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. mkennedy@gentoo.org 2006-10-15 00:09:09 0000 You might want to file a bug then. emerge --info, a back trace etc. gmsoft@gentoo.org 2006-10-15 06:51:27 0000 Stable on hppa. agriffis@gentoo.org 2006-10-15 13:58:26 0000 (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 falco@gentoo.org 2006-10-18 05:34:05 0000 Let's go for a GLSA. bug 151503 seems not very common. falco@gentoo.org 2006-10-26 15:14:55 0000 GLSA 200610-08