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

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

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

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

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

Hi,