Additional hardening options


Paul Eggleton
 

Hi folks

I've been looking into a couple of compiler flags for hardening that I think we
might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu, Fedora).


2) -z noexecstack (or alternative mitigations)

gcc will enable an executable stack under a few different circumstances - see
here for details

https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

I've written a check that we could add to insane.bbclass that warns/errors on
binaries with an executable stack. Does this seem reasonable to have?
The other possibility is we add -Wl,-z,noexecstack to LDFLAGS and then see
what breaks, but unfortunately issues are likely only going to show up when
the program crashes at runtime, and also it will stop the aforementioned check
from working.


Any opinions?

Thanks
Paul


Paul Eggleton
 

On Wednesday, 26 January 2022 14:39:39 NZDT Paul Eggleton wrote:
Hi folks

I've been looking into a couple of compiler flags for hardening that I think
we might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu,
Fedora).
Another quirk of this - with dunfell, the buildepoxy SDK test fails on Ubuntu
18.04 with -fstack-clash-protection because the version of meson in dunfell
uses the same LDFLAGS value for both host and target, and host gcc doesn't
support that option. Not sure what to do other than just filtering out the
option from LDFLAGS in the test.

Cheers
Paul


Alexander Kanavin
 

I guess you can submit a patch, and it can be taken for a spin on the autobuilder?

Alex


On Wed, 26 Jan 2022 at 22:17, Paul Eggleton <bluelightning@...> wrote:
On Wednesday, 26 January 2022 14:39:39 NZDT Paul Eggleton wrote:
> Hi folks
>
> I've been looking into a couple of compiler flags for hardening that I think
> we might want to consider enabling by default in security-flags.inc:
>
>
> 1) -fstack-clash-protection
>
> This option was introduced to gcc 8.x and provides protection against the
> stack clash vulnerability:
>
> https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html
>
> It has been enabled in some Linux distributions already (e.g. Ubuntu,
> Fedora).

Another quirk of this - with dunfell, the buildepoxy SDK test fails on Ubuntu
18.04 with -fstack-clash-protection because the version of meson in dunfell
uses the same LDFLAGS value for both host and target, and host gcc doesn't
support that option. Not sure what to do other than just filtering out the
option from LDFLAGS in the test.

Cheers
Paul






Khem Raj
 

On Wed, Jan 26, 2022 at 1:17 PM Paul Eggleton
<bluelightning@...> wrote:

On Wednesday, 26 January 2022 14:39:39 NZDT Paul Eggleton wrote:
Hi folks

I've been looking into a couple of compiler flags for hardening that I think
we might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu,
Fedora).
That is good testimony, it will be good to know how this option
impacts performance
and does it work across architectures and libc's supported in OE.


Another quirk of this - with dunfell, the buildepoxy SDK test fails on Ubuntu
18.04 with -fstack-clash-protection because the version of meson in dunfell
uses the same LDFLAGS value for both host and target, and host gcc doesn't
support that option. Not sure what to do other than just filtering out the
option from LDFLAGS in the test.

Cheers
Paul





Richard Purdie
 

On Wed, 2022-01-26 at 14:39 +1300, Paul Eggleton wrote:
Hi folks

I've been looking into a couple of compiler flags for hardening that I think we
might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu, Fedora).


2) -z noexecstack (or alternative mitigations)

gcc will enable an executable stack under a few different circumstances - see
here for details

https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

I've written a check that we could add to insane.bbclass that warns/errors on
binaries with an executable stack. Does this seem reasonable to have?
The other possibility is we add -Wl,-z,noexecstack to LDFLAGS and then see
what breaks, but unfortunately issues are likely only going to show up when
the program crashes at runtime, and also it will stop the aforementioned check
from working.


Any opinions?
These seem like reasonable things to do, are there any downsides to them?

I'd be happy to test some patches, see if they do cause issues...

Cheers,

Richard


Robert Berger
 

Hi,

This[1] is what I usually add as well to the security flags.

With respect to the "default" flags I had some fun with the SDK and -D_FORTIFY_SOURCE=2 and -fstack-protector-strong.

I guess they do have some performance impact as well, but I did not do very thorough research.

Also, I did not confirm it yet but suspect that some of those flags might be the reason for "debuginfod gdb: *** stack smashing detected ***: terminated".[2]

[1] https://gitlab.com/meta-layers/meta-resy/-/blob/master/conf/distro/include/more_security_flags.inc

[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14570

Regards,

Robert


Bernhard Rosenkränzer <bero@...>
 

Hi,

On Wed, Jan 26, 2022 at 02:39 AM, Paul Eggleton wrote:
I've been looking into a couple of compiler flags for hardening that I think we
might want to consider enabling by default in security-flags.inc:
1) -fstack-clash-protection
2) -z noexecstack (or alternative mitigations)
I've been looking into those flags (and a few more) a while back when picking compiler flags to use for Oniro.

-Wl,-z,-noexecstack is unproblematic, -fstack-clash-protection adds a bit of overhead, but it isn't all that bad (typically in the 2% range).

I've been able to build working systems with both flags enabled.

My full report is at
https://forum.ostc-eu.org/t/compiler-flags-to-be-used-for-all-scenarios-os/94

ttyl
bero