Bug 196978 - app-arch/cpio safer_name_suffix buffer overflow (CVE-2007-4476)
|
Bug#:
196978
(CVE-2007-4476)
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: major
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: rbu@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441444
|
|
Summary: app-arch/cpio safer_name_suffix buffer overflow (CVE-2007-4476)
|
|
Keywords:
|
|
Status Whiteboard: A2? [glsa]
|
|
Opened: 2007-10-24 23:06 0000
|
Seems like cpio also ships this code. A patch is attached to the Debian bug in
URL.
Base-system, please advise.
it isnt a bug in tar or cpio or any package ... the code in question is part of
gnulib, so any package that utilizes gnulib's paxnames.c file is in trouble
err, it isnt part of gnulib, it's part of paxutils ... so any project that
imports paxutils is affected ;)
but a quick grep of my /var/log/portage/ (~9000 logs) shows only cpio and tar
building up "paxnames.c"
cpio-2.9-r1 in the tree with the code taken from tar-1.19
Arches, please test and mark stable app-arch/cpio-2.9-r1.
Target keywords : "alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc
x86"
alpha/ia64/sparc/x86 stable
(In reply to comment #3)
> but a quick grep of my /var/log/portage/ (~9000 logs) shows only cpio and tar
> building up "paxnames.c"
>
which lets me to the question whether the tar package should be patched too ?
afaik, tar-1.19 is already fixed ... if someone wants to double check ...
This should go to release snapshot
(In reply to comment #6)
> (In reply to comment #3)
> > but a quick grep of my /var/log/portage/ (~9000 logs) shows only cpio and tar
> > building up "paxnames.c"
> >
> which lets me to the question whether the tar package should be patched too ?
Only tar <= 1.16 is affected by this, and that's vulnerable to GLSA 200709-09
anyway.
Still waiting for amd64 for release... I'd like to bump the priority, but don't
know how that might affect security team rules (and too lazy to look... ;p) so
I'm leaving it alone.
====amd64====
1. Compiles.
2. Installs.
3. Test all ok.
4. Runs fine as well.
Portage 2.1.3.16 (default-linux/amd64/2007.0/desktop, gcc-4.1.2,
glibc-2.6.1-r0, 2.6.22-gentoo-r8 x86_64)
=================================================================
System uname: 2.6.22-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3400+
Timestamp of tree: Fri, 02 Nov 2007 01:47:01 +0000
ccache version 2.4 [enabled]
app-shells/bash: 3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python: 2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache: 2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox: 1.2.18.1-r2
sys-devel/autoconf: 2.13, 2.61-r1
sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils: 2.18-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool: 1.5.24
virtual/os-headers: 2.6.22-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/distfiles"
FEATURES="ccache collision-protect distlocks metadata-transfer multilib-strict
nostrip parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
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
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/overlay"
SYNC="rsync://kv80/gentoo-portage"
USE="X acl acpi aim alsa amd64 arts berkdb bitmap-fonts branding cairo cli
cracklib crypt cups dbus dri dvd dvdread emboss encode esd evo fam firefox
fortran gdbm gif gpm gstreamer hal iconv imap ipv6 isdnlog jpeg kde kerberos
mad midi mikmod mmx mp3 mpeg mqsli mudflap mysql ncurses nls nptl nptlonly
nvidia ogg opengl openmp oss pam pcre pdf perl png pppd python qt3 qt3support
quicktime readline reflection sdl session sockets spell spl sqlite3 sse sse2
ssl svg tcpd test tiff truetype truetype-fonts type1-fonts unicode vim
vim-syntax vorbis xcomposite xine xml xorg xv zlib" ALSA_CARDS="ali5451 als4000
atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968
fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop
empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi
null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard
mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780
lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS
rPATH is disputing the impact of this:
Previous versions of the cpio and tar packages are vulnerable to a
Denial of Service attack in which an attacker can use a malformed
archive file to cause a stack-based buffer overflow, crashing the
application. It is not believed that this vulnerability can be
exploited to execute malicious code.
Also see: https://issues.rpath.com/browse/RPL-1861
The original Suse description:
This update fixes a bug in cpio in function safer_name_suffix() which
leads to a crashing stack. Exploitability is unknown. (CVE-2007-4476)
This leaves us somewhere between A2 and A4. How do we proceed?
Stabline doesn't hurt so I suggest we continue stabling and decide later wether
to release a GLSA or not.
If someone have the time to examine this closer now, they're welcome:-)
amd64 stable (worked, passed all 4 tests)
amd64 stable (worked, passed all 4 tests)
yestooGLSArequestfiledkthxbye
mips got stabled at some point by someone....