Re: Improved PIE binary tooling

[Ed Maste]

On Thu, 4 Jun 2020 at 20:15, Dewayne Geraghty
 wrote:
>
> Thank-you Ed.  Though I have two questions:
>
> 1. We've recompiled all the ports I use with either -fPIC or -fPIE and
> the linker flag -pie. Is there something required for ports to utilise
> these changes, or are the changes only in the mk files affecting the
> base system build?

No additional change is needed - the linker will automatically add
this flag when -pie is specified.

> 2. I've also taken advantage of employing -fstack-clash-protection,
> unfortunately this is currently only available via gcc (we're using gcc9
> at the moment).  Does the fact that we use gcc9 and binutils 2.33.1
> influence the outcome of your changes?

Mmm, good question - the LLD commit indicated that binutils should set
this too, but I haven't tried. You can check `readelf -d` on one of
your PIE binaries, and if the flag is not set probably submit a PR
against devel/binutils.

-fstack-clash-protection is in Clang now, but it landed after 10.0.
The next Clang update will include it. (It was actually committed and
reverted four times, but stuck on the fifth try.)
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Improved PIE binary tooling

[Dewayne Geraghty]

Thank-you Ed.  Though I have two questions:

1. We've recompiled all the ports I use with either -fPIC or -fPIE and
the linker flag -pie. Is there something required for ports to utilise
these changes, or are the changes only in the mk files affecting the
base system build?

2. I've also taken advantage of employing -fstack-clash-protection,
unfortunately this is currently only available via gcc (we're using gcc9
at the moment).  Does the fact that we use gcc9 and binutils 2.33.1
influence the outcome of your changes?

Regards, Dewayne
PS an interesting aside, there are a surprising number of ports that use
the _FORTIFY_SOURCE=2 so the application developers are well
intentioned, a nice (though futile) effort, because libc doesn't have
the *_chk macros.  At least we're all heading in the right direction to
deny malcontents easy unauthorised access. :)

On 5/06/2020 12:23 am, Ed Maste wrote:
> Kostik and I recently committed a couple of changes to improve PIE
> binary support:
> 
> r361725 Do not allow to load ET_DYN object with DF_1_PIE flag set.
> r361740 lld: Set DF_1_PIE for -pie
> 
> Previously there could be ambiguity as to whether an object is a
> shared library (DSO) or Position Independent Executable (PIE) binary;
> a PIE is in fact a special type of DSO. These changes add a .dynamic
> flag DF_1_PIE that's used to unambiguously indicate that an object is
> a PIE binary, and disallow the use of dlopen() or DT_NEEDED on that
> binary.
> 
> Future changes should have file(1) report "position independent
> executable" or similar instead of "shared object". Some desktop
> environments / file managers have had issues refusing to execute PIE
> binaries, and tagging them should also address those.
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
> 

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"