Bug 172746 - {kde-base/kdelibs-3.5.5-r10|x11-libs/qt} UTF 8 issues (CVE-2007-0242)
|
Bug#:
172746
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: minor
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: jaervosz@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: {kde-base/kdelibs-3.5.5-r10|x11-libs/qt} UTF 8 issues (CVE-2007-0242)
|
|
Keywords:
|
|
Status Whiteboard: A4 [noglsa] jaervosz
|
|
Opened: 2007-03-30 06:22 0000
|
Reported by Dirk Mueller from KDE:
a significant bug in the Qt (3.x and 4.x) UTF 8
decoder, that in certain cases can lead to security vulnerabilies. It causes
XSS errors at least in Konqueror, though any KDE application that deals with
urls or paths from untrusted locations can be affected.
The issue is that the UTF8 decoder incorrectly does not reject overlong
sequences, which can cause "/../" injection or (in the case of konqueror)
a "<script>" tag injection.
Not sure which packages are affected. KDE please advise.
Sorry, just found this bug. See 172784.
*** Bug 172784 has been marked as a duplicate of this bug. ***
I have been informed this is assigned as CVE-2007-0242
*** Bug 173304 has been marked as a duplicate of this bug. ***
*** Bug 173303 has been marked as a duplicate of this bug. ***
The x11-libs/qt side should be addressed by:
qt-3.3.8-r2
qt-4.2.3-r1
I think both are candidates for stability anyway, so asking arches to go stable
shouldn't be an issue.
------
The kde-base/kdelibs side should be addressed by:
kde-base/kdelibs-3.5.6-r4 and kde-base/kdelibs-3.5.5-r10, the latter of which
looks like it's going stable now. So, I think that's the version (3.5.5-r10)
we should address, since 3.5.6 isn't stabilized yet as a whole.
Thx Caleb.
kde-base/kdelibs-3.5.5-r10 is all stable on bug #172527.
Arches please test and mark stable. Target keywords are:
qt-3.3.8-r2.ebuild:KEYWORDS="alpha amd64 hppa ia64 mips ppc ppc64 sparc x86
~x86-fbsd"
qt-4.2.3-r1.ebuild:KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86
~x86-fbsd"
Both packages stable on amd64.
x11-libs/qt-3.3.8-r2
x11-libs/qt-4.2.3-r1
~dev-db/qt-unixODBC-3.3.8
stable on ia64 + x86
qt4 fails miserably on sparc with a simple and quite informative:
qtdemo: xcb_xlib.c:50qtdemo: xcb_xlib.c:50: xcb_xlib_unlock: Assertion
`c->xlib.lock' failed.
Aborted
Ideas anyone?
Look at the output of configure and see if it's detecting your system on sparc
correctly. We have a patch in the ebuild that should help it, but it's from
the 4.1 series so maybe the patch needs to be updated.
(In reply to comment #16)
> qt4 fails miserably on sparc with a simple and quite informative:
>
> qtdemo: xcb_xlib.c:50qtdemo: xcb_xlib.c:50: xcb_xlib_unlock: Assertion
> `c->xlib.lock' failed.
> Aborted
Exact same error on hppa for media-sound/qmpdclient-1.0.7:
qmpdclient: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
> Ideas anyone?
>
Not yet.
Build log [3.8 MB]:
http://www.xs4all.nl/~rooversj/gentoo/bugs/x11-libs:qt-4.2.3-r1:20070411-204654.log
Thu Apr 12 03:31:35 CEST 2007
Portage 2.1.2.3 (default-linux/hppa/2006.1, gcc-4.1.1, glibc-2.3.6-r5,
2.6.19.1-pa0-JeR parisc)
=================================================================
System uname: 2.6.19.1-pa0-JeR parisc PA8700 (PCX-W2)
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 11 Apr 2007 15:50:01 +0000
distcc 2.18.3 hppa2.0-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [disabled]
dev-lang/python: 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache: 2.4-r6
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.17.50.0.12
sys-devel/gcc-config: 1.3.15-r1
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.11-r5
ACCEPT_KEYWORDS="hppa"
AUTOCLEAN="yes"
CBUILD="hppa2.0-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mschedule=8000 -march=2.0 -ggdb -Wall"
CHOST="hppa2.0-unknown-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 /var/bind
/var/www/localhost/htdocs/wordpress/wp-config.php"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php4/ext-active/
/etc/php/apache1-php5/ext-active/ /etc/php/apache2-php4/ext-active/
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/
/etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -mschedule=8000 -march=2.0 -ggdb -Wall"
DISTDIR="/keeps/gentoo/distfiles"
FEATURES="autoaddcvs buildpkg cvs distlocks fixpackages notitles sandbox
sfperms splitdebug strict"
GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/
http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/
http://ftp.rhnet.is/pub/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo "
LC_ALL="en_US.UTF-8"
LINGUAS="en nl he"
MAKEOPTS="-j2"
PKGDIR="/keeps/gentoo/packages/elmer"
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="/keeps/gentoo/portage"
PORTDIR_OVERLAY="/keeps/gentoo/local"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="7zip X Xaw3d a52 aac aalib accessibility alsa amr ao aoss apache2 ares
arts asf audiofile avahi bash-completion berkdb bidi bitmap-fonts bittorrent bl
bzip2 c++ cairo caps catalogs cdb cdparanoia cdr chardet cjk cli cpudetection
cpufreq cracklib crypt cups curl custom-cflags dbus dcraw dga directfb doc dts
dv dvd dvdread dxr3 edl elf enca encode esd exif expat fam fame fastbuild
fastcgi fbcon ffmpeg firefox flac foomaticdb fortran ftp gd gdbm ggi gif
gimpprint glitz glut gmp gnome gnutls gphoto2 gpm gs gtk gtk2 gtkhtml hal hppa
icecast iconv idn imagemagick imlib immqt-bc inquisitio ipv6 isdnlog javascript
jpeg jpeg2k kde kdeenablefinal kerberos lcms ldap libcaca libnotify
libsamplerate libwww logrotate lua lzo mad matroska memcache mhash midi mikmod
mmap mng modplug motif mozbranding mp3 mudflap musepack mysql nas ncurses
netpbm nfs nls offensive ogg openexr opengl oss pam pch pcre pdf perl php pic
plugins png portaudio postgres povray pppd pulseaudio python qt3 readline
recode reflection rpc rrdtool rtc ruby samba sasl scanner scim sdl session sid
slang slp sndfile snmp speex spell spl sqlite ssl startup-notification suhosin
svg sysfs tcl tcpd tetex tga theora threads thunar-vfs tidy tiff timidity tk
truetype truetype-fonts twolame type1-fonts udev unicode unzip usb userlocales
utempter utf v4l v4l2 vanim vcd vidix vim-syntax vorbis wavpack webdav wlan wma
wmf xanim xattr xcb xchattext xcomposite xface xml xml2 xorg xrandr
xscreensaver xv xvid xvmc zeroconf zip zlib" ALSA_CARDS="ad1889 usb-audio"
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" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LINGUAS="en nl he" USERLAND="GNU" VIDEO_CARDS="stifb fbdev matrox"
Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
To understand, the build doesn't fail, but running the qtdemo causes that
error?
Re comments 18 and 19:
> Build type: linux-g++
> Architecture: parisc
Note there is a patch "qt4-parisc-linux.diff" that is NOT being applied in
4.2.3 but was in earlier versions. I don't know if this may need to be
reactivated or not.
Exactly, also designer fails if it means anything.
IIRC without the patch things were built wrong for sparc in such a way that it
would SIGBUS (or killed by some other signal rather than just aborting).
(In reply to comment #21)
> Note there is a patch "qt4-parisc-linux.diff" that is NOT being applied in
> 4.2.3 but was in earlier versions.
That is because it WON'T apply to >=qt-4.2. It kills poor epatch. :)
(In reply to comment #23)
> it was strange to me that alpha doesn't fail and I was investigating a bit.
>
> Probably, the error is well documented by debian in:
> http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html
>
> Error and patch could be found in:
> https://bugs.freedesktop.org/show_bug.cgi?id=8581
>
> And alpha (also probably) doesn't fail because we don't have:
> x11-proto/xcb-proto-1.0, x11-libs/libxcb-1.0, x11-libs/libX11-1.1.1-r1 marked
> as stable.
>
>
> Excuse me if I'm completely wrong with my assumptions
You were completely right. Rebuilding libX11 with USE=-xcb did the job.
Both Qts are now stable for HPPA.
(In reply to comment #25)
> You were completely right. Rebuilding libX11 with USE=-xcb did the job.
>
Sounds like a bug.
@X11: please see the problem described in comments #16 and #18 and read #23 to
check the root of the problem. Possibly related with the bug #156367?
Thanks.
gustavoz, can you post the beginning of your build log. I'd like to make sure
it's catching that your system is a sparc system.
caleb: no need for that, if i build libX11 with USE="xcb" on x86 it fails
miserably the same way. I'm rebuilding libX11 with no xcb on sparc to check it
out but it seems Yoswink and Jer pinpointed the issue nicely and i think it'll
work.
We either mask xcb globally or fix qt4. I'd rather choose the second option
since it's qt's fault.
Oh and qt-3.3.8-r2 sparc stable since it's not affected by this.
Verified, qt4 against libX11 -xcb on sparc works just fine.
Anyone having XCB locking errors, please ensure all your X libraries are
current. In particular, these ones:
$ grep -i -e xcb -e lock /usr/portage/x11-libs/libX*/ChangeLog -l
/usr/portage/x11-libs/libX11/ChangeLog
/usr/portage/x11-libs/libXcomposite/ChangeLog
/usr/portage/x11-libs/libXdamage/ChangeLog
/usr/portage/x11-libs/libXfixes/ChangeLog
/usr/portage/x11-libs/libXi/ChangeLog
/usr/portage/x11-libs/libXrandr/ChangeLog
(In reply to comment #30)
> Anyone having XCB locking errors, please ensure all your X libraries are
> current. In particular, these ones:
@Donnie: if current == stable then yes, they are. But I've seen in ChangeLogs
that many of these fixes are marked as ~arch, so most of the users don't hit
them and maybe we'll see the bugs growing up in bugzilla.
Any plan about how to deal with the bug?
Thanks.
There's a few bugs around relating to this same thing. My response is, let's
just stable the stuff. I haven't yet filed a bug for that, though. Any
objections or support?
(In reply to comment #32)
> There's a few bugs around relating to this same thing. My response is, let's
> just stable the stuff. I haven't yet filed a bug for that, though. Any
> objections or support?
>
I've been meaning to file such a thing when I have time to figure out all the
packages that need to go stable.
(In reply to comment #33)
> (In reply to comment #32)
> > There's a few bugs around relating to this same thing. My response is, let's
> > just stable the stuff. I haven't yet filed a bug for that, though. Any
> > objections or support?
> >
>
> I've been meaning to file such a thing when I have time to figure out all the
> packages that need to go stable.
>
Well, I'm with you as far as I can't see any better solution. Please, if we are
going to do a fast-stable-keywording, package versions with only fixes for this
bug and no new features or code added would be perfect. Anyway, If you think
the new versions are ready for stable, I trust you :)
I just filed bug #174959 to stable some XCB-fixed libraries. It's not a "fast"
stable keywording by any means. Only one of those libraries has been in the
tree for just 1 month, the others for many more.
Bug #174959 stabling fixed the xcb issues, qt-4.2.3-r1 sparc stable.
(In reply to comment #35)
> I just filed bug #174959 to stable some XCB-fixed libraries. It's not a "fast"
> stable keywording by any means. Only one of those libraries has been in the
> tree for just 1 month, the others for many more.
@Donnie and Joshua: thanks guys, you rock.
alpha done.
This one is ready for GLSA decision. I tend to vote NO.
Hi,
Since qt-3.3.8-r2 went stable with the utf8 patch some people, including me,
have
some issue with kmail that we describe in bug #174678 .
Removing the utf8 patch restore the functionality, is there a forgotten corner
case in the patch or has the patch revealed a bug in kmail?
I haven't seen any information about kmail issues. Can you describe the
problem and I'll ask the packagers?
(note: let's do it in a new bug, to keep from CCing everyone here)
(In reply to comment #40)
> I haven't seen any information about kmail issues. Can you describe the
> problem and I'll ask the packagers?
>
As I have already mentioned in my original comment it is all in bug #174678
I just thought I'd bring it to your attention since we identified the utf8
patch as the source of the problem.
also tending to vote no
that makes one full no vote so far
not a "trivial" XSS (overly long sequences needed) -> i vote no, and closing.
Feel free to reopen if you disagree.