| Summary: | dev-util/cmake < 2.6.1 links executable with insecure RUNPATHs | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | Runpath Issues | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | brad.king, galtgendo, holger, kde, loki_val, matsuu, matthew.m.mccormick, peper |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | ~2 [noglsa] | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
cmake-utils-rpath.patch
Patch from upstream cmake fixing this bug. Applies cleanly to 2.6.1. |
||
|
Description
Diego Elio Pettenò (RETIRED)
2008-06-04 15:44:25 UTC
CCing KDE team as it might be caused by cmake 2.6.0 Okay this seems to be related to cmake 2.6.0 and this warning in particular:
CMake Warning (dev) at index/CMakeLists.txt:42 (add_library):
Policy CMP0003 should be set before this line. Add code such as
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 NEW)
endif(COMMAND cmake_policy)
as early as possible but after the most recent call to
cmake_minimum_required or cmake_policy(VERSION). This warning appears
because target "sopranoindex" links to some libraries for which the linker
must search:
I got this error out of soprano, and it also has the same NULL DT_RUNPATH. And good enough it seems a quite big security risk (if it wasn't for scanelf).
This is not caused by cmake 2.6, but fixed by cmake 2.6. To use they better version, use cmake 2.6, and put
if(COMMAND cmake_policy)
cmake_policy(VERSION 2.6)
endif()
in your topmost CMakeLists.txt
For more information, see
cmake --help-policies
and look at 0003
I will be filing a bug to unmask cmake 2.6
(In reply to comment #2)
> Okay this seems to be related to cmake 2.6.0 and this warning in particular:
> CMake Warning (dev) at index/CMakeLists.txt:42 (add_library):
> Policy CMP0003 should be set before this line. Add code such as
>
> if(COMMAND cmake_policy)
> cmake_policy(SET CMP0003 NEW)
> endif(COMMAND cmake_policy)
>
> as early as possible but after the most recent call to
> cmake_minimum_required or cmake_policy(VERSION). This warning appears
> because target "sopranoindex" links to some libraries for which the linker
> must search:
>
> I got this error out of soprano, and it also has the same NULL DT_RUNPATH. And
> good enough it seems a quite big security risk (if it wasn't for scanelf).
>
The new cmake policy is better security-wise, but I don't know if will help with the problem mentioned. For more info, check http://www.cmake.org/Wiki/CMake_RPATH_handling From what I understand, you would want the 'Always Full RPATH' option? As far as I can see with this individual applications will need to be patched to use the correct policy. I will admit to not being an RPATH guru but it also seems to me that the RPATH handling has been improved, it just needs to be set up correctly by the application. I am not sure if some of the CMake files will also need patching to find the libraries they are linking to also. I do think it is important to bring CMake 2.6.0 out of package mask. A simple fix, add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to options. http://markmail.org/message/7fexrgbrawejuhpl CMake maintains a separate RPATH for binaries in the build tree and binaries in the install tree. The idea is to make it easy to run a binary that uses shared libraries in its own build tree. When the binary is installed (make install) CMake sets the RPATH for the install tree copy of the binary to be whatever was specified by the project (or removes the entry completely if nothing was specified). CMake has built-in chrpath functionality (which improves over the original tool by supporting cross compiling). It uses this to switch the RPATH in the installed binary. When the RPATH specified for the installed binary is longer than the RPATH needed for running from the build tree, CMake reserves space in the build-tree copy by appending ':' characters to fill up the space. This is what creates the empty RPATH entries. However, these entries never get installed. The final binary always has the RPATH specified by the project for the install tree copy. What -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON does is to tell CMake to create a new binary for installation by linking again in order to set the new RPATH for the install tree. In this case there is no need to reserve space, so the build-tree copy does not get the ':' characters appended. Another fix is to tell CMake that we don't care about running from the build tree so it should just link with the final install-tree RPATH right away: -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON This will avoid the re-linking step and avoid creating empty RPATH entries in any copy of the binary. If someone can tell me how to reserve extra space in the RPATH string through a standard linker interface without creating a bogus path, I'd love to use it instead of appending ':' characters. (In reply to comment #7) > Another fix is to tell CMake that we don't care about running from the build > tree so it should just link with the final install-tree RPATH right away: USE="test" often runs things in the build tree, no? Maybe something to consider. I suggest to add -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=1 and -DCMAKE_BUILD_WITH_INSTALL_RPATH=1 to cmake-utils.eclass as cmake-2.6.1/CMakeLists.txt. Created attachment 162856 [details, diff]
cmake-utils-rpath.patch
I finally got access to a friend's gentoo box and was able to reproduce this problem. It looks like the gentoo linker is using --enable-new-dtags by default. Using this flag on my debian machine I was able to reproduce the problem too. The bug is that CMake removes only the DT_RPATH entry and zeroes its string. The DT_RUNPATH entry is left intact but it refers to the same string data which have now been zeroed so it becomes an empty string. I've committed a fix to CMake HEAD in CVS. We'll include the fix in the 2.6.2 release. >
> I've committed a fix to CMake HEAD in CVS. We'll include the fix in the 2.6.2
> release.
>
Awesome. Thanks for working so hard on this.
(In reply to comment #11) > I've committed a fix to CMake HEAD in CVS. We'll include the fix in the 2.6.2 > release. > Any ETA for this release? otherwise could you indicate the exact CVS diff so we can patch 2.6.0 until 2.6.2 is out? Thanks. Created attachment 163847 [details, diff]
Patch from upstream cmake fixing this bug. Applies cleanly to 2.6.1.
Here is a patch I generated to backport the fix to 2.6.1.
I've just added cmake-2.6.1 to the tree which applies the patch kindly provided by upstream, big thanks Brad! Arches, please test and mark stable dev-util/cmake-2.6.1. Target keywords: "alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd" Wait -- Did this ever affect any stable system? As far as I understand, cmake 2.6* has been under p.mask until very recently. in fact, it is still masked. Un-cc'ing arches. Just to make sure: Our stable (pre 2.6.0) was not affected by this behaviour? I am bringing cmake-2.6.1 out of package mask as all looks well now. Is there any reason this bug is still open? (In reply to comment #19) > I am bringing cmake-2.6.1 out of package mask as all looks well now. Is there > any reason this bug is still open? > Yes, as rbu pointed out in comment #18, we need to know if cmake < 2.6 was affected or not since it was stable. If no, we can close this bug. If yes, we'll probably need to stable a fixed version. The code in question was introduced in CMake 2.6.0, so there is no problem for 2.4.x and below. Thanks, closing then. |