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.
Created attachment 114905 [details, diff]
Created attachment 114906 [details, diff]
Created attachment 114907 [details, diff]
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:
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.
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.
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.
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.
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.
> Ideas anyone?
Build log [3.8 MB]:
Thu Apr 12 03:31:35 CEST 2007
Portage 220.127.116.11 (default-linux/hppa/2006.1, gcc-4.1.1, glibc-2.3.6-r5, 18.104.22.168-pa0-JeR parisc)
System uname: 22.214.171.124-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]
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
CFLAGS="-O2 -pipe -mschedule=8000 -march=2.0 -ggdb -Wall"
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"
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 "
LINGUAS="en nl he"
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-*"
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).
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:
Error and patch could be found in:
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
(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:
> Error and patch could be found in:
> 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?
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
(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?
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.
This one is ready for GLSA decision. I tend to vote NO.
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.