Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 116027 - dev-lang/cm3-5.2.7_pre050331 insecure RUNPATHs/TEXTRELs/executable stacks
Summary: dev-lang/cm3-5.2.7_pre050331 insecure RUNPATHs/TEXTRELs/executable stacks
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Runpath Issues (show other bugs)
Hardware: x86 Linux
: High minor (vote)
Assignee: SpanKY
Whiteboard: B3 [ebuild]
Depends on:
Blocks: 81745
  Show dependency tree
Reported: 2005-12-19 04:08 UTC by Patrick Lauer
Modified: 2007-01-24 04:48 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

cm3-5.2.6-RUNPATH.patch (cm3-5.2.6-RUNPATH.patch,233 bytes, patch)
2006-01-13 12:22 UTC, Tupone Alfredo
Details | Diff
cm3-5.2.6.ebuild.patch (cm3-5.2.6.ebuild.patch,643 bytes, patch)
2006-01-13 12:28 UTC, Tupone Alfredo
Details | Diff
cm3-5.2.7_pre050331.ebuild (cm3-5.2.7_pre050331.ebuild.patch,613 bytes, patch)
2006-01-13 13:04 UTC, Tupone Alfredo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Lauer gentoo-dev 2005-12-19 04:08:51 UTC
I guess this is already known, but just for completeness:
QA Notice: the following files contain insecure RUNPATH's
/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-sys/m3quake/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-sys/m3middle/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-libs/libm3/LINUXLIBC6:/var/tmp/portage/cm3-5.2.7_pre050331/work/m3-libs/m3core/LINUXLIBC6:/usr/lib/cm3//lib usr/lib/cm3/pkg/m3cgcat/LINUXLIBC6/m3cgcat
QA Notice: the following files contain runtime text relocations
[long list]
QA Notice: the following files contain executable stacks
[long list]
!!! ERROR: dev-lang/cm3-5.2.7_pre050331 failed.
Comment 1 SpanKY gentoo-dev 2005-12-19 19:46:30 UTC
cm3 is based upon gcc-3.2.x but it should be easy to fix the exec stacks
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-12-20 04:15:18 UTC
No clue, as usual.
Comment 3 Tupone Alfredo gentoo-dev 2006-01-13 12:22:16 UTC
Created attachment 77023 [details, diff]

Fixing RUNPATH, by building the offensive program static
Comment 4 Tupone Alfredo gentoo-dev 2006-01-13 12:28:09 UTC
Created attachment 77025 [details, diff]

change  to the ebuild. 
hmm ... I applied those to 5.2.6 :/ Bug is related to 5.2.7 
5.2.6 build and merge correctly. cm3 is not usable as produce the problem described by Bug 116028

I hope that solution works for 5.2.7
Comment 5 Tupone Alfredo gentoo-dev 2006-01-13 13:04:22 UTC
Created attachment 77027 [details, diff]

cm3-5.2.7 works :) with the same patch. Just rename the patch to cm3-5.2.7_pre050331-RUNPATH.patch
Comment 6 solar (RETIRED) gentoo-dev 2006-01-13 13:21:33 UTC
linking static is not the right solution.
Comment 7 Tupone Alfredo gentoo-dev 2006-01-14 06:30:33 UTC
(In reply to comment #6)
> linking static is not the right solution.

I wonder why ...

Any piece of cm3 suite is built standalone :/
Comment 8 solar (RETIRED) gentoo-dev 2006-01-14 12:09:25 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > linking static is not the right solution.
> > 
> I wonder why ...
> Any piece of cm3 suite is built standalone :/

linking static has sometimes some advantages but often disadvantages.
Think what happens if there is some obscure vuln in glibc. You now have
a copy of that vuln libc.a when the cm3 was built linked into the
executable forever and no easy way to detect that it linked in the old
libc. Linking static also makes larger in size and memory hungy apps.
Often the simple way to fix the rpath problems is to replace the
code in makefile's where you see -Wl,-R,"/path" with a simple -L "/path"
That allows it to link and have no unresolved symbols, without having the
hardcoded rpath value during normal runtime. If the -L does not work
due to it needing that path so it can run itself after building itself
and needs to find those libs which it linked to (which is not cross
compile friendly) then we can sometimes export LD_RUNPATH=/path
Comment 9 Tupone Alfredo gentoo-dev 2006-01-14 18:40:05 UTC
I know what linking static imply. But if you look at all the binary that cm3 provide, they were are all static, except the one that I changed, and the compiler.

Anyway, the compiler is the only piece that you can see where is linked. 
All the other piece are built with the "make" like cm3 system. There is no -L or rpath specification there. It is all elaborated automatically, with the same tools that cm3 provide.

So, unless you fix this tools, so you can build in a different place that the one they are to be shipped, there is nothing you can do. 

Unless you build static.

Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2006-01-15 09:17:36 UTC
vapier: your opinion as maintainer ?
Comment 11 Tupone Alfredo gentoo-dev 2006-01-16 05:33:01 UTC
Well, I suppose another solution is viable: writing a tool that strip from the runpath string of the exe or shared libs, the "/var/tmp/portage/xxx/image/" thing.
And calling this for any exe/shared lib encountered during the merge phase, or manually driven inside the ebuild.
I'm not able to do this now :(
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2006-01-16 05:40:35 UTC
The tool exists and is called chrpath... but that means pulling it as a build-time dep. Why not, I guess maintainer has now two choices :)
Comment 13 solar (RETIRED) gentoo-dev 2006-03-05 08:02:47 UTC
The next ~arch portage revision will auto repair evil rpaths and not bail. 
Maintainers should still fix the packages they maintain as portage will only die
with FEATURES=stricter (but that is a maintainer & QA problem) no longer security@
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2006-09-21 03:29:10 UTC
No longer a security issue with current stable portage, re-assigning to maintainer
Comment 15 SpanKY gentoo-dev 2007-01-24 04:48:51 UTC
cm3 no longer in portage