Message: previous - next
Month: November 2011

Re: [trinity-devel] kdelibs potential security vulnerability

From: Serghei Amelian <serghei@...>
Date: Fri, 11 Nov 2011 20:28:38 +0200
On Friday 11 November 2011 20:12:13 /dev/ammo42 wrote:
> Hello,
> The kdelibs/qt3 combination I built (from the stable sources) has a
> security hole: when the dynamic loader loads, the
> 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.

Seems like your binaries still have RPATH. RPATH should be removed at install