|Summary:||dev-libs/libiconv has an RPATH starting with $PORTAGE_TMPDIR value (similar to GLSA 200503-01)|
|Product:||Gentoo Security||Reporter:||René Rhéaume (a.k.a. repzilon, rener) <rene.rheaume>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Whiteboard:||~3 [noglsa] jaervosz|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description René Rhéaume (a.k.a. repzilon, rener) 2005-04-29 11:52:44 UTC
I emerged libiconv to be able to build glib2 on a uclibc-based install. Few days later, I checked my system using a script I made and I got this output: >Searching ELF binaries on the system. It will take a while. >These binaries have RPATH set: >/usr/bin/iconv > RPATH /var/tmp/portage/libiconv-1.9.2/image//usr/lib I also ran readelf on it $ readelf -d /usr/bin/iconv | egrep 'RPATH|RUNPATH' 0x0000000f (RPATH) Library rpath: [/var/tmp/portage/libiconv-1.9.2/image//usr/lib] 0x0000001d (RUNPATH) Library runpath: [/var/tmp/portage/libiconv-1.9.2/image//usr/lib] This is similar to bug #75181 , a.k.a GLSA 200503-01. Gentoo BSD team should be informed of this bug as soon as possible. Reproducible: Always Steps to Reproduce: Expected Results: No insecure RPATH is hard-coded into /usr/bin/iconv
Comment 1 René Rhéaume (a.k.a. repzilon, rener) 2005-04-29 12:36:22 UTC
I originnaly thought a dosed or a patch would do the trick. Unfortunately, this issue more arcane. I found out that if libiconv was not installed (whether never on unmerged prior to emerging), the iconv executable will contain an RPATH. But if I emerge again without prior unmerging (a rebuild), RPATH is gone!
Comment 2 solar (RETIRED) 2005-04-29 17:06:44 UTC
Created attachment 57629 [details, diff] libiconv-1.9.2-chrpath-ebuild.patch This patch makes use of the chrpath command to remove the rpath in the src_install() phase. chrpath is tiny (13k)
Comment 3 Diego Elio Pettenò (RETIRED) 2005-04-29 20:07:33 UTC
I'm going to test if chrpath works on g/fbsd, if it doesn't we need to find a new way to handle this. Please next time cc me as I'm libiconv's maintainer.
Comment 4 Diego Elio Pettenò (RETIRED) 2005-04-29 20:10:50 UTC
Seems like the problem isn't there on g/fbsd but just on linux. Need KERNEL USE_EXPANDED to fix this, really need that ASAP now.
Comment 5 Diego Elio Pettenò (RETIRED) 2005-04-29 20:23:33 UTC
Added a new revision which uses chrpath unconditionally but is masked on fbsd, waiting to have KERNEL in USE_EXPAND. Added sparc to cc as I had to drop ~sparc keyword as it misses chrpath.
Comment 6 SpanKY 2005-04-29 21:11:25 UTC
cant we fix this without resorting to chrpath ?
Comment 7 Sune Kloppenborg Jeppesen (RETIRED) 2005-04-29 23:44:26 UTC
Diego, we normally CC people on any security bugs as soon as it gets wrangled, which is now. Solar was just faster than me this time around.
Comment 8 Martin Schlemmer (RETIRED) 2005-04-30 03:43:45 UTC
Created attachment 57664 [details, diff] libiconv-1.9.2-RPATH-fix.patch Whoever added the libtool support should be shot.
Comment 9 Martin Schlemmer (RETIRED) 2005-04-30 03:53:50 UTC
Created attachment 57666 [details, diff] libiconv-1.9.2-RPATH-fix-2.patch This works also if you want the more minimal solution.
Comment 10 Diego Elio Pettenò (RETIRED) 2005-04-30 04:31:07 UTC
Thanks I've added your patch and libiconv is happy both on linux and fbsd. It also has again the ~sparc keyword.
Comment 11 Sune Kloppenborg Jeppesen (RETIRED) 2005-05-11 07:19:13 UTC
As this is unstable -> closing with NO GLSA.