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 attachment 46559 [details, diff] 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
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.
