Bugzilla Bug 163989

CHM files contain various tables and objects stored in "pages." When parsing a
page of objects, CHMlib passes an unsanitized value from the file to the
alloca() function. This allows an attacker to shift the stack pointer to point
to arbitrary locations in memory. Consequently it is possible to write
arbitrary data from the file to arbitrary memory locations.

Successful exploitation of this vulnerability allows an attacker to execute
arbitrary code with the permissions of the user viewing the file. An attacker
would have to first convince the user to view the CHM file through some type of
social engineering.

Reproducible: Didn't try




http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=468

chmlib-0.39 is now in the tree.  amd64, hppa, ppc, and x86 need to be stabled.

thanks Ryan

arches, please test and ... well you know...


didn't add hppa, since it has not been stable there before

app-doc/chmlib-0.39
1. emerges on x86
2. passes collision test
3. app-doc/kchmviewer-2.5 emerges and works fine

Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4,
2.6.19.2 i686)
=================================================================
System uname: 2.6.19.2 i686 Genuine Intel(R) CPU           T2300  @ 1.66GHz
Gentoo Base System version 1.12.6
Last Sync: Fri, 26 Jan 2007 16:31:02 +0000
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.31
dev-lang/python:     2.3.5-r3, 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.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
CHOST="i686-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/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--nospinner"
FEATURES="autoconfig collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/"
LINGUAS="en de en_GB de_CH"
MAKEOPTS="-j3"
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"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X a52 aac acpi alsa apache2 asf berkdb bitmap-fonts cairo cdr cdrom
cli cracklib crypt cups dbus divx dlloader dri dts dvd dvdr dvdread eds
elibc_glibc emboss encode fam ffmpeg firefox flac fortran gdbm gif gnome gpm
gstreamer gtk hal iconv input_devices_keyboard input_devices_mouse ipv6 isdnlog
java jpeg kde kdeenablefinal kernel_linux ldap libg++ linguas_de linguas_de_CH
linguas_en linguas_en_GB mad mikmod mmx mono mp3 mpeg ncurses nls nptl nptlonly
ogg opengl oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline
reflection rtsp ruby samba sdl session smp spell spl sse sse2 sse3 ssl svg tcpd
test tetex theora threads truetype truetype-fonts type1-fonts udev unicode
userland_GNU vcd video_cards_fbdev video_cards_i810 video_cards_vesa vorbis
win32codecs wxwindows x264 xine xml xorg xprint xv xvid zlib"
Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

x86 stable

ppc stable

amd64 stable

all vulnerable versions now booted from the tree.

Are we going to bother with a GLSA on this one?

Oops, my bad, looks like one is already being drafted.

(In reply to comment #8)
> Are we going to bother with a GLSA on this one?
> 

B2 == yes

200702-12, sorry for the delay