Bugzilla Bug 75181

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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
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/libmng.so.1",
O_RDONLY) = -1 ENOENT (No such file or directory)
...

etc.

$ readelf -d /usr/qt/3/lib/libqt-mt.so.3 | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/var/tmp/portage/qt-3.3.3/work/qt-x11-free-3.3.3/lib]

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,libqt-mt.so.3
-Wl,-rpath,/var/tmp/portage/qt-3.3.3-r1/work/qt-x11-free-3.3.3/lib

I have a patch in that filters it out of the uic Makefile, but apparently I'm
not getting all instances of it.

Created an attachment (id=46559) [details]
proposed fix

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.

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 

http://www.gentoo.org/doc/en/faq.xml#tmpportage
http://forums.gentoo.org/viewtopic.php?t=30547

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/libpng.so.3
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 :)

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! :)

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

Caleb: your patch does fix the issue here, and seems to be inline with what
other distros are doing..could you apply this patch?

Committed as 3.3.4-r2

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.

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.

Thx Caleb.

Arches please test 3.3.4-r2 and report back results here. Do not mark stable yet.

looks good on ppc64. (but I only have launched a few apps of kde..)  Markus

Looking good on sparc

Looking good on amd64.

Looks good on ppc.

Looks good on alpha.

I'm not using any qt apps.. can other x86 devs can test it ?

x86 looks fine here.

Caleb, I think we're ready to go on all supported arches.

FYI:

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.

I haven't had any problems here with 6.8.2 and qt 3.3.4-r2.

I've just marked 3.3.4-r2 x86 stable.

caleb, are we ready to mark the arches stable that tested this already?

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.

stable on ppc64

arches, feel free to mark the ebuild stable then since caleb agrees

(removing x86 from CC, cause it's already marked stable there)

sparc stable.

ppc stable

Alpha stable.

done on ia64

done on ia64

Sorry for the delay - there was another pending bug for this library I had to
investigate. Now stable on amd64.

Stable on mips.

Thx everyone.

GLSA 200503-01

hppa please remember to mark stable.

-r3 already stable on hppa.

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/libQtCore.so | grep "PATH" 
 0x000000000000000f (RPATH)              Library rpath: [/usr/qt4/lib] 
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/qt4/lib] 

@Roland, this issue is closed. Please open a new bug and assign it to the KDE
team.