Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 75181 - x11-libs/qt: libqt rpath may allow local users to hijack qt applications
Summary: x11-libs/qt: libqt rpath may allow local users to hijack qt applications
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: A3? [glsa] jaervosz
Depends on:
Blocks: 81745
  Show dependency tree
Reported: 2004-12-21 07:24 UTC by Tavis Ormandy (RETIRED)
Modified: 2008-01-13 14:12 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

proposed fix (rpath.patch,352 bytes, patch)
2004-12-21 12:00 UTC, Caleb Tennis (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2004-12-21 07:24:51 UTC
it looks like qt remembers it's build directory under $BUILD_PREFIX (eg, /var/tmp/portage) and searches there for shared libraries to dlopen as required, regardless of LD_LIBRARY_PATH.

This could be a security issue, if tmp directories are cleared out by an administrator doing some spring cleaning (eg, rm -rf /var/tmp/portage) or if there is a mailicious user in group portage (group portage has write permission under /var/tmp/portage, eg: drwxrwxr-x  47 portage portage 1544 Dec 21 14:47 /var/tmp/portage/), a malicious user could create common libraries such as libpng or libmng and inject code into other users qt applications.

Ideally, qt should not try searching this for shared libraries to open.

example, with opera:

$ strace -e open opera 2>&1 | grep "/var/tmp/portage"
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/i686/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/i686/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)

etc, and here's one with qtorrent:

$ strace -e open qtorrent 2>&1 | grep "/var/tmp/portage"
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/i686/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/i686/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/tls/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/i686/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)

Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2004-12-21 08:15:01 UTC
$ readelf -d /usr/qt/3/lib/ | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib]
Comment 2 Simone Gotti (RETIRED) gentoo-dev 2004-12-21 08:52:43 UTC
probably qmake adds an -rpath ${current build} dir in the Makefile. Can this be the problem?

# cd /var/tmp/portage/qt-3.3.3-r1/work/qt-x11-free-3.3.3

# grep "rpath" src/Makefile
LFLAGS   = -fno-exceptions -shared -Wl,-soname, -Wl,-rpath,/var/tmp/portage/qt-3.3.3-r1/work/qt-x11-free-3.3.3/lib
Comment 3 Caleb Tennis (RETIRED) gentoo-dev 2004-12-21 09:43:17 UTC
I have a patch in that filters it out of the uic Makefile, but apparently I'm not getting all instances of it.
Comment 4 Caleb Tennis (RETIRED) gentoo-dev 2004-12-21 12:00:37 UTC
Created attachment 46559 [details, diff]
proposed fix
Comment 5 Caleb Tennis (RETIRED) gentoo-dev 2004-12-21 12:15:59 UTC
Note that I think I've tried deleting this instance of rpath before, and it made the compilation of Qt fail, but that could have been in an older version.
Comment 6 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-05 09:32:02 UTC
I think this is a fairly serious problem, not just a theoretical one...I might be missing something though, perhaps I should explain why I think this is an issue...

portage encourages the adding of users to group portage if they are going to use emerge, it's not a big deal...

*** You are not in the portage group. You may experience cache problems
*** due to permissions preventing the creation of the on-disk cache.
*** Please add this user to the portage group if you wish to use portage.

Once you're in group portage, you have write permissions in PORTAGE_TMPDIR, and if you can get a file into /var/tmp/portage/qt-x.y.z/work/qt-x11-free-x.y.z/lib/, you can control anyone's qt applications.

The gentoo faq says it's safe to clean out /var/tmp/portage

If an admin does this (and if you google for rm -rf /var/tmp/portage, you can see lots do), anyone in group portage can run code as any user who uses qt apps.

exploitation is simple:

$ mkdir -p /var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib
$ gcc -shared rpath.c -o /var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib/
now when someone runs opera (or some other app)...
$ opera
exploit code now in control!
opera: Activated running instance of Opera

Here's the code from rpath.c:

#include <stdio.h>

void __attribute__ ((constructor)) rpath_exploit (void);

void rpath_exploit (void)
        fprintf (stderr, "exploit code now in control!\n");
        /* insert evil code here */

Okay, this isn't a huge threat to gentoo security, but i really think it needs to be fixed :)
Comment 7 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-05 09:40:50 UTC
Also, I havnt tried it, but if someone were to install qt from a tbz2, would the directory be present? if not, anyone in group portage can just create it.

Even worse, if someone uses a different PORTAGE_TMPDIR from whoever built qt, or if they change the directory after building it, you don't even need to be in group portage...if you can write to /var/tmp (everyone), you're in business! :)
Comment 8 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-05 14:54:10 UTC
I've just checked the qt.spec used in fedora, they have this:

# don't use rpath
perl -pi -e "s|-Wl,-rpath,| |" mkspecs/*/qmake.conf
Comment 9 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-08 09:54:44 UTC
Caleb: your patch does fix the issue here, and seems to be inline with what other distros are doing..could you apply this patch?
Comment 10 Caleb Tennis (RETIRED) gentoo-dev 2005-02-09 17:53:27 UTC
Committed as 3.3.4-r2
Comment 11 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-09 21:58:13 UTC
Thx Caleb,
are there any outstanding major problems with 3.3.4? If not Security will call arches to mark 3.3.4-r2 stable.
Comment 12 Caleb Tennis (RETIRED) gentoo-dev 2005-02-10 04:10:34 UTC
I think a bump to stable is in order, but I'd like to hold off on promoting it for a little bit yet to make sure there are no negative implications of Qt not having rpath built into the library.
Comment 13 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-10 04:27:25 UTC
Thx Caleb.

Arches please test 3.3.4-r2 and report back results here. Do not mark stable yet.
Comment 14 Markus Rothe (RETIRED) gentoo-dev 2005-02-10 12:22:37 UTC
looks good on ppc64. (but I only have launched a few apps of kde..)  Markus
Comment 15 Jason Wever (RETIRED) gentoo-dev 2005-02-11 06:08:23 UTC
Looking good on sparc
Comment 16 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-02-11 06:10:56 UTC
Looking good on amd64.
Comment 17 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-02-11 09:39:29 UTC
Looks good on ppc.
Comment 18 Bryan Østergaard (RETIRED) gentoo-dev 2005-02-11 17:09:48 UTC
Looks good on alpha.
Comment 19 Olivier Crete (RETIRED) gentoo-dev 2005-02-13 12:49:56 UTC
I'm not using any qt apps.. can other x86 devs can test it ?
Comment 20 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-14 11:32:21 UTC
x86 looks fine here.

Caleb, I think we're ready to go on all supported arches.
Comment 21 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-19 04:12:35 UTC

After further testing there might be a problem. Since upgrading to xorg 6.8.2 and qt 3.3.4-r2 I've had the main Konqueror window pane consistingly refusing to load twice and the message pane in Kmail once. Restarting solved the problem. I have not encountered the problem with xorg 6.8.2 and the current stable qt. Unfortunately I don't have the time to test any further and pin the problem for the coming week.
Comment 22 Caleb Tennis (RETIRED) gentoo-dev 2005-02-19 07:10:28 UTC
I haven't had any problems here with 6.8.2 and qt 3.3.4-r2.
Comment 23 Caleb Tennis (RETIRED) gentoo-dev 2005-02-23 05:24:48 UTC
I've just marked 3.3.4-r2 x86 stable.
Comment 24 Matthias Geerdsen (RETIRED) gentoo-dev 2005-02-23 05:42:37 UTC
caleb, are we ready to mark the arches stable that tested this already?
Comment 25 Caleb Tennis (RETIRED) gentoo-dev 2005-02-23 06:11:33 UTC
As far as I'm concerned, yes.  I have noted no problems with it other than the typical "you may have to re-emerge kdelibs after upgrading qt" bug report.
Comment 26 Markus Rothe (RETIRED) gentoo-dev 2005-02-23 10:38:46 UTC
stable on ppc64
Comment 27 Matthias Geerdsen (RETIRED) gentoo-dev 2005-02-23 12:16:55 UTC
arches, feel free to mark the ebuild stable then since caleb agrees

(removing x86 from CC, cause it's already marked stable there)
Comment 28 Gustavo Zacarias (RETIRED) gentoo-dev 2005-02-23 17:48:37 UTC
sparc stable.
Comment 29 Jochen Maes (RETIRED) gentoo-dev 2005-02-24 06:20:16 UTC
ppc stable
Comment 30 Bryan Østergaard (RETIRED) gentoo-dev 2005-02-24 10:01:29 UTC
Alpha stable.
Comment 31 Aron Griffis (RETIRED) gentoo-dev 2005-02-25 08:58:16 UTC
done on ia64
Comment 32 Aron Griffis (RETIRED) gentoo-dev 2005-02-25 08:58:23 UTC
done on ia64
Comment 33 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-03-01 03:47:19 UTC
Sorry for the delay - there was another pending bug for this library I had to investigate. Now stable on amd64.
Comment 34 Hardave Riar (RETIRED) gentoo-dev 2005-03-01 08:27:14 UTC
Stable on mips.
Comment 35 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-03-01 10:18:18 UTC
Thx everyone.

GLSA 200503-01

hppa please remember to mark stable.
Comment 36 René Nussbaumer (RETIRED) gentoo-dev 2005-06-26 05:09:42 UTC
-r3 already stable on hppa.
Comment 37 Roland Harnau 2008-01-09 21:58:28 UTC
Are there any reasons why  RPATH/RUNPATH header entries are still suppressed in recent Qt4 ebuilds/eclasses? E.g. qt-4.3.3.ebuild contains the somewhat redundant lines

# Do not link with -rpath. See bug #75181.
sed -i -e "s:QMAKE_RPATH.*=.*:QMAKE_RPATH=:" qmake.conf
# Do not link with -rpath. See bug #75181.
sed -i -e "s:QMAKE_RPATH.*=.*:QMAKE_RPATH=:" g++.conf
myconf="-stl -verbose -largefile -confirm-license \
-platform ${PLATFORM} -xplatform ${PLATFORM} -no-rpath \

When I build Qt 4.3.3 myself outside Gentoo (configured with -prefix /usr/qt4) I get the correct behavior, i.e. RPATH/RUNPATH is set to the library install path. E.g.  

readelf -d /usr/qt4/lib/ | grep "PATH" 
 0x000000000000000f (RPATH)              Library rpath: [/usr/qt4/lib] 
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/qt4/lib] 


Comment 38 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-01-13 14:12:22 UTC
@Roland, this issue is closed. Please open a new bug and assign it to the KDE team.