Ticket #1132 (closed general: fixed)

Opened 10 months ago

Last modified 3 months ago

libtool + %global _hardened_build 1 = no full hardening

Reported by: besser82 Owned by:
Priority: critical Keywords:
Cc: packaging-team@… Blocked By:
Blocking:

Description

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.

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

# dirty hack to force immediate binding with hardenend build having
# autocrap's libtool pass the need gcc-specs to linker.
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,
Björn


[1] http://tk-blog.blogspot.de/2009/02/relro-not-so-well-known-memory.html
[2] https://admin.fedoraproject.org/pkgdb/acls/name/hardening-check
[3] http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00003.html

Change History

comment:1 Changed 10 months ago by besser82

I just did some testing on F19 for libs shipped by 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!

comment:2 Changed 10 months ago by notting

  • Keywords meeting added

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.

comment:3 Changed 10 months ago by sgallagh

Deferring for a week to wait for Adam Jackson's comments on https://bugzilla.redhat.com/show_bug.cgi?id=978949

comment:4 Changed 9 months ago by toshio

Deferred another week waiting for input from ajax.

comment:5 Changed 9 months ago by mitr

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.

comment:6 Changed 9 months ago by mitr

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.

comment:7 Changed 9 months ago by mmaslano

Patch will be applied by nirik.

comment:8 Changed 9 months ago by mmaslano

Is the libtool hack applied or not? I did see comments about broken buildroot after applying the original patch.

comment:9 Changed 9 months ago by sgallagh

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.

comment:10 follow-up: ↓ 14 Changed 9 months ago by toshio

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.

comment:11 Changed 9 months ago by kevin

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).

comment:12 Changed 9 months ago by toshio

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.

comment:13 Changed 9 months ago by mmaslano

+1 for postpone to F-21 and finding better fix.

comment:14 in reply to: ↑ 10 Changed 9 months ago by mitr

Replying to toshio:

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.

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.

comment:15 Changed 9 months ago by mitr

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).

comment:16 Changed 9 months ago by pjones

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.

comment:17 Changed 9 months ago by mmaslano

It's +5, please postpone this feature for F-21 where can be used proper solution.

comment:18 Changed 9 months ago by mitr

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.

comment:19 Changed 8 months ago by sgallagh

  • Keywords meeting removed

comment:20 Changed 4 months ago by toshio

  • Keywords Meeting added

The F21 Change Process has opened. We probably need to start discussion on this gain.

comment:21 Changed 4 months ago by kkofler

I still think that the right fix for this issue is to just relibtoolize the packages.

comment:22 Changed 4 months ago by tmraz

mitr, Can you please post the "new" %configure hack here?

comment:23 Changed 4 months ago by tmraz

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.

comment:24 Changed 4 months ago by toshio

+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.

comment:25 Changed 4 months ago by sgallagh

+1 to applying after New Year's.

comment:26 Changed 3 months ago by tmraz

  • Keywords Meeting removed

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.

comment:27 Changed 3 months ago by kevin

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.