build: shared library should have noexecstack set

[bnoordhuis]

A non-executable stack prevents certain classes of security vulnerabilities.

-Wl,-z,noexecstack is set when building a binary but not when building a shared library (node_shared=="true", corresponding to ./configure --shared.)

Since the execstack bit is transitive, any binary linking to a shared library with an executable stack also ends up with an executable stack.

The practical impact is probably low because noexecstack is the default on many systems but it would be good to:

1. Be explicit for consistency across platforms and toolchains, and

2. Have a test that checks noexecstack is set on the build product. It could check the output of execstack -q filename but that might be Linux-only.

[yhwang]

1. Be explicit for consistency across platforms and toolchains

Looks like Windows provides it by default (starting with Windows XP and Windows Server 2003)
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366553(v=vs.85).aspx

For AIX, it provides a system level Stack Execution Disable(SED) feature:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm
It's on by default and I don't see linker options for this.

MacOSX also turns on the NX bit by default:
https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
It provides options to turn it off (but no options to explicitly turn it on)

So, maybe we just need to explicitly use noexecstack in linux and freebsd.

[Trott]

I wonder if this is of value to @nodejs/embedders and, if so, if maybe one of them might be up for tackling it. 😄

[aixtools]

As this is still open - and I am the new guy on the block:

re: AIX - since POWER4 (roughly 2001) the POWER platform (and AIX) has provided SED (stack execution disable) - regardless of anything done by the compiler or linker.

However, the default was, and is - to only provide the ability, not enforce it by default.

aixtools@x064:[/home/aixtools]sedmgr
Stack Execution Disable (SED) mode: select
SED configured in kernel: select

This means programs and shared-libraries may _select_ively active SED.

aixtools@x064:[/home/aixtools]sedmgr -d /usr/lib/libpython3.6.so
/usr/lib/libpython3.6.so : system
aixtools@x064:[/home/aixtools]sedmgr -d /opt/bin/python3
/opt/bin/python3 : system

In this example - since both the executable and the library are in "system" mode, and the system is select, SED is not enforced - as it was not selected.

After the following (as root or RBAC enabled)

**root**@x064:[/home/root]sedmgr -c request /opt/bin/python3
_aixtools_@x064:[/home/aixtools]sedmgr -d /opt/bin/python3
/opt/bin/python3 : request

Python - and I assume all the libraries that are used - are SED enabled.

Note: What is general practice?

• The system setting gets set to 'all'

root@x064:[/home/root]sedmgr -m all
System wide SED attribute has been set successfully. It is effective at 64 bit kernel boot time.
root@x064:[/home/root]sedmgr
Stack Execution Disable (SED) mode: all
SED configured in kernel: select

IMHO: as far as build is concerned - gcc has, and recent XLC compilers has support for a compile option (that may do something regardless of AIX SED settings) none are required. The checks can (and, imho, should) be performed by the processor.

Hope this helps (more than a link to documentation that can 'move')!

Michael

[jayaddison]

What's the current availability of expert time & guidance to help resolve this?

[jayaddison]

Based on guidance at https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks and https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart, it's worth adding a .note.GNU-stack section to assembly code when an executable stack isn't required by the resulting assembled binary.

Applying that guidance might not completely resolve this issue, but should contribute towards it. Does anyone have time to write or review that change? (if only review time's available, then I can prepare and push a relevant commit)

[bnoordhuis]

I believe this was fixed in 90008f8? Closing, but please reopen if I'm mistaken.