Ticket #1132 (closed general: fixed)

Opened 2 years ago

Last modified 17 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 2 years 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 2 years 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 23 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 23 months ago by toshio

Deferred another week waiting for input from ajax.

comment:5 Changed 23 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 23 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 22 months ago by mmaslano

Patch will be applied by nirik.

comment:8 Changed 22 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 22 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 22 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 22 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 22 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 22 months ago by mmaslano

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

comment:14 in reply to: ↑ 10 Changed 22 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 22 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 22 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 22 months ago by mmaslano

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

comment:18 Changed 22 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 22 months ago by sgallagh

  • Keywords meeting removed

comment:20 Changed 17 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 17 months ago by kkofler

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

comment:22 Changed 17 months ago by tmraz

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

comment:23 Changed 17 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 17 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 17 months ago by sgallagh

+1 to applying after New Year's.

comment:26 Changed 17 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 17 months ago by kevin

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