= phenomenon =
When building libraries with autotools, libtool does not pass all {C, LD}FLAGS, exported properly by %configure-macro, to the linker causing "partial" RELRO [1] instead of the expected fully hardened build.
%configure
hardening-check [2] reports:
{{{ Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found! }}}
Using the following hack/work-around after %configure-macro in spec-file
{{{
sed -i -e 's! \\$compiler_flags !&\\$CFLAGS \\$LDFLAGS !' libtool }}}
makes hardening-check report:
{{{ Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes }}}
So this simple (but effective) hack makes sure ALL hardening-relevant flags are passed by libtool to the linker.
= reason =
By it's design libtool omits all {C, LD}FLAGS which are not portable to other platforms. This is a feature bug, known but not fixed, for ages. [3] That's why custom gcc-specs set in {C, LD}FLAGS are not passed when linking the built lib.
= recommendation =
Append the following code (needs to be adapted) to %configure-macro in all maintained Fedora-releases provided by the rpm package and trigger a mass rebuild && security update for all packages having hardening-build enabled and using autotools/libtool on all maintained Fedora-releases.
{{{ if [ -f ./libtool ] ; then sed -i -e 's! \\$compiler_flags !&\\$CFLAGS \\$LDFLAGS !' libtool ; fi ; }}}
Thanks for your attention,[[BR]] Björn
[1] http://tk-blog.blogspot.de/2009/02/relro-not-so-well-known-memory.html [[BR]] [2] https://admin.fedoraproject.org/pkgdb/acls/name/hardening-check [[BR]] [3] http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00003.html
I just did some testing on F19 for libs shipped by [https://fedoraproject.org/wiki/Hardened_Packages packages which MUST be hardened] and saw with great surprise that at least gdm (libgdm.so) and abrtd (libabrt.so) are affected by this.
hardening-check /usr/lib64/libgdm.so.1.0.0 {{{ Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! Fortify Source functions: unknown, no protectable libc functions used Read-only relocations: yes Immediate binding: no, not found! }}} hardening-check /usr/lib64/libabrt_dbus.so.0.0.1 {{{ Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! Fortify Source functions: unknown, no protectable libc functions used Read-only relocations: yes Immediate binding: no, not found! }}} hardening-check /usr/lib64/libabrt.so.0.0.1 {{{ Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found! }}}
Some discussion at 2013-06-26 FESCo meeting, but: AGREED: re: #1132 1) mass rebuild at this time rejected (will rebuild f20 later), 2) defer to next week to allow proper analysis (+:5, -:0, 0:0)
Setting 'meeting' keyword for next week.
Deferring for a week to wait for Adam Jackson's comments on https://bugzilla.redhat.com/show_bug.cgi?id=978949
Deferred another week waiting for input from ajax.
Agreed today's FESCo meeting (+5): Apply kludge to redhat-rpm-config now, ask libtool maintainer to come up with a more sustainable/better fix in libtool and drop kludge when no longer needed.
Noted the resolution in https://bugzilla.redhat.com/show_bug.cgi?id=978949 , filed https://bugzilla.redhat.com/show_bug.cgi?id=985592 against libtool.
I'm keeping the ticket open for now, due to the impact on mass rebuild.
Patch will be applied by nirik.
Is the libtool hack applied or not? I did see comments about broken buildroot after applying the original patch.
My understanding was that this needed to be rolled back because it was causing other issues. I tried to look into it a little myself, but it quickly went far over my head.
I'm going to suggest that we defer this to Fedora 21 while we try to find a proper libtool solution and instead document mechanisms that packagers can use to patch the build environments of their packages to fix this in the meantime.
nirik confirmed that it was rolled back. I wouldn't be opposed to this remaining a F20 feature but with reduced scope (due to missing the mass rebuild) or with the feature owners doing more work to ensure that everything needing to be rebuilt was rebuilt.
yes, it was rolled back.
I am +1 to punting this for now, and fixing gdm/abrt in spec (or any other cases we can identify).
Hopefully by f21 we can have a more sane libtool. (yeah, I know, I know).
I think we're at +3 for not blocking the mass rebuild on this. We need two more +1's to allow the mass rebuild to go forward without it.
+1 for postpone to F-21 and finding better fix.
Replying to [comment:10 toshio]:
Note that this is not a feature, it was proposed directly in this tracker, so it currently doesn't have an "owner" other than the libtool package maintainer who owns the libtool bug.
I've talked to praiskup (libtool owner), we should have an analysis of the feasibility of a fix (!= the fix itself) in a few days.
That gives us a clear plan to eventually move forward, so I'm +1 to not blocking the mass rebuild on this (~= postponing to F21).
It seems we've run out of time for this release, so I'm also +1 to not blocking the mass rebuild, and solving this for F21.
It's +5, please postpone this feature for F-21 where can be used proper solution.
Pavel Raiskup has looked at this and will try to push the long-term fix upstream, and highlighted that we'll need a %configure hack or per-package workarounds in any case, to deal with tarballs created with an older version of libtool.
He's also proposed a new %configure hack; I wouldn't mind getting this into F20 but given the previous hack I don't think rushing it in is worth the risk.
The F21 Change Process has opened. We probably need to start discussion on this gain.
I still think that the right fix for this issue is to just relibtoolize the packages.
mitr, Can you please post the "new" %configure hack here?
So this is the latest version of the %configure hack: https://bugzilla.redhat.com/attachment.cgi?id=782186
It should not bring the same regressions as the hack that was applied before in Rawhide. Of course there might be other, more subtle, regressions from this one, but currently we do not know about any.
I propose to apply it to redhat-rpm-config in Rawhide.
+1 to applying but let's wait until after New Years to apply it. Since the last attempt to change this broke builds I wouldn't want us to break builds again while people who can fix it are on vacation.
+1 to applying after New Year's.
AGREED: Apply the %configure hack (with possible opt-out) as of https://bugzilla.redhat.com/attachment.cgi?id=838954 (+7, 0, 0)
Nirik, please close the ticket once you apply the hack.
Applied in rawhide.
Announced:
https://lists.fedoraproject.org/pipermail/devel-announce/2014-January/001292.html
Login to comment on this ticket.