trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: November 2011

kdelibs potential security vulnerability

From: /dev/ammo42 <mickeytintincolle@...>
Date: Fri, 11 Nov 2011 19:12:13 +0100
Hello,
The kdelibs/qt3 combination I built (from the stable sources) has a
security hole: when the dynamic loader loads libkdecore.so, the
libmng.so.1 is first searched in a directory in /tmp, which could
potentially result in a local root privilege escalation if there are
suid binaries which depend on kdelibs on the target system.
Even without suid binaries, on a multi-user system one could gain
another user's privileges by letting them load a kdelibs-using binary
while a forged libmng is present in the /tmp directory (and usually
can't be deleted by a regular user because of the sticky bit in /tmp).
The build script I use does
$ export LD_LIBRARY_PATH=$TMP/build-qt3/qt3/lib:$LD_LIBRARY_PATH
(actually Calvin Morrison's PKGBUILD does the same thing).
Perhaps this hack has a relation with the issue, but anyway Patrick
Volderking (the creator of Slackware) mentions in his old build script
for Qt3 (when KDE3 was in Slackware) that building Qt3 in /tmp gives
****, and his script builds qt3 directly on $PREFIX/lib{,64}/qt (or qt3,
depending on the exact script). But I'm not sure this is compatible
with all distribution policies… as another means of avoiding /tmp, the
gcc Slackware build scripts which use /$(mcookie) as a temporary
directory.
Are official binaries affected by the issue ? I don't know Debian/Red
Hat building procedures at all and then I have no idea of the answer.