On Mon, Aug 25, 2008 at 11:54:26PM +0200, Luca Capello wrote: > Hi Bill! > > For the ECL list: this is a 'serious' bug in the Debian BTS [1]. For > the reason why rpath is considered harmful by Debian see [2] and [3]. > > Please don't Cc: me, I read the list. However, please keep the Debian > bug cc:ed (no need to subscribe), I set the M-F-T and R-T to both the > bug and the mailing list to facilitate the above :-) > > On Wed, 20 Aug 2008 10:55:51 +0200, Bill Allombert wrote: > > Hello Debian Common Lisp Team, > > ecl includes a ELF file /usr/lib/ecl/asdf.fas with a rpath pointing to > > /tmp/buildd/ecl-0.9j-20080306/build/. > > If I'm not wrong, this is a design decision, which seems to be > officially documented at [4]. However, it's strange that the rpath is > pointing to /tmp/... and not /usr/lib/ecl/.
This is why I reported the bug: A rpath of /usr/lib/ecl/ is not a problem if it is intended. However a rpath of /tmp/buildd/ecl-0.9j-20080306/build/ is a security hole since /tmp is world-writable: an attacker can just 'mkdir -p /tmp/buildd/ecl-0.9j-20080306/build/' and then add trojaned shared library there, and wait for someone to load /usr/lib/ecl/asdf.fas and compromise their account. > > This allows an attacker with write access to that directory to > > add modified libraries which will be loaded when someone > > else run ecl. > > I've added the ECL list to cc:. While I can easily remove the rpath as > explained at [3], I'll wait for upstream's voice :-) Instead of removing it, if /usr/lib/ecl/ was the intended rpath, you can just replace the rpath with /usr/lib/ecl/. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
