build: enable ASLR (PIE) on OS X

[woodfairy]

After conducting several benchmarks, I noticed performance losses of
5-10%. As OS X is not a performance critical platform, as already
mentioned by @bnoordhuis, I have removed the -no_pie flag at least for
this platform. I'd love to enable PIE for other platforms if the 5-10%
speed loss is not too high. I would be happy to hear your opinion on
this.

Refs: #33425

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[addaleax]

Since common.gypi also affects addons: Should we be extra careful and label this semver-major?

[richardlau]

Since common.gypi also affects addons: Should we be extra careful and label this semver-major?

Probably. Does it have to be in common.gypi? Could it be in node.gypi instead?

[woodfairy]

Since common.gypi also affects addons: Should we be extra careful and label this semver-major?

Probably. Does it have to be in common.gypi? Could it be in node.gypi instead?

As PIE is explicitly opted-out in common.gypi, and there is no "-no_pie" flag in node.gypi, I wouldn't know how to turn it on specifically in node.gypi. But maybe I am missing some knowledge here. My changes actually just revert this commit: a5012a0

[richardlau]

ugh then I guess defensively semver-major it is 😞.

[Trott]

@nodejs/tsc This is semver-major and so would need at least one more TSC approval.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/33994/

[mmarchini]

CI is passing, so I assume #5903 is not an issue anymore? If someone wants to build a custom Node.js binary without PIE, how would they do it?

[mcollina]

Blocking this as I would like to know more. what is the advantage of -pie?

A lot of frontend build tools compete on build times, e.g. performance. I disagree that Mac is not a perf-critical target.

[addaleax]

what is the advantage of -pie?

@mcollina To save you a Google search, it enables the OS to do ASLR which is a security feature: https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables & https://en.wikipedia.org/wiki/Address_space_layout_randomization

Apple's macOS and iOS fully support PIE executables as of versions 10.7 and 4.3, respectively; a warning is issued when non-PIE iOS executables are submitted for approval to Apple's App Store but there's no hard requirement yet and non-PIE applications are not rejected.

[mmarchini]

a warning is issued when non-PIE iOS executables are submitted for approval to Apple's App Store but there's no hard requirement yet and non-PIE applications are not rejected

ah that's why my inbox is full of alerts?

[mcollina]

I looked at those articles, however I do not understand exactly what is the benefit and what we are trying to protect our users from. None of the threat exposed there seems to apply to our security model.

[addaleax]

@mcollina It’s a defense-in-depth mechanism that mitigates the impact of remote code execution vulnerabilities. It is an additional layer to make exploits significantly harder to write, rather than a full protection against a vulnerability. It is also fairly standard to have this enabled in modern applications, if that is technically feasible.

[mhdawson]

My take is that 5-10% is a significant decrease and we need to carefully weigh if the benefits are worth that decrease, particularly in the eyes of end users.

[mcollina]

Does python, ruby, etc ships with this enabled? Does go, rust produce binaries with this enabled by default?

[mmarchini]

FWIW, I think we already have it enabled for Linux builds, and I think it's not a performance problem on Linux (although I might be wrong), so when evaluating Python, Ruby, Go, etc. those should be evaluated on OSX as well.

[addaleax]

Does python, ruby, etc ships with this enabled?

Yes, and, at least on my Ubuntu machine, they also do so on Linux.

Does go, rust produce binaries with this enabled by default?

Rust does and go doesn’t, on both of these platforms.

Also, keep in mind that this does not affect compiled JS code, only native code in the binary.

[mmarchini]

I'm very surprised by the 5-10% numbers tbh

[mhdawson]

I'm very surprised by the 5-10% numbers tbh

Particularly if we already have it enabled for Linux.

[addaleax]

I'm very surprised by the 5-10% numbers tbh

Particularly if we already have it enabled for Linux.

It doesn't look like we do, though.

[woodfairy]

Blocking this as I would like to know more. what is the advantage of -pie?

A lot of frontend build tools compete on build times, e.g. performance. I disagree that Mac is not a perf-critical target.

PIE / ASLR is an exploit mitigation which makes it harder to exploit a target if you find a memory bug (e.g. stack buffer overflow) which would allow arbitrary code execution. With PIE enabled, you can't hardcode addresses, and you need to calculate offsets for them. To achieve this, another vulnerability would be needed (e.g. format string information leak) in order to circumvent this. From my personal experience writing (basic) exploits, PIE is a very useful mitigation. Especially in combination with W^X mempages, PIE is a very effective way to prevent return-oriented programming (which is a common technique when writing exploits). In my opinion, the security benefits outweigh the perfomance costs.

Does go, rust produce binaries with this enabled by default?

Rust does and go doesn’t, on both of these platforms.

Also, keep in mind that this does not affect compiled JS code, only native code in the binary.

Rust and Go don't need this feature as they are memory safe by design (Rust at compile-time via RAII, Golang at runtime via garbage collector). The developers say, that their languages are safe and therefore no need for PIE, which is not the case for C / C++.

[mcollina]

This is a really good protection layer but I also think it is very theoretical in the Node.js case. I may be wrong but I don't think there has been an RCE in the last few years (if not one at all). We consider JS code as "trusted" - there are significant bigger threats if we did not consider it so.

[woodfairy]

This is a really good protection layer but I also think it is very theoretical in the Node.js case. I may be wrong but I don't think there has been an RCE in the last few years (if not one at all). We consider JS code as "trusted" - there are significant bigger threats if we did not consider it so.

It is not very theoretical, and it does not have to be an RCE, as I've said this is relevant for any memory based attack. It is not about JS code, it's about the native code, which you can never consider safe if it's C or C++. This is a standard security feature in modern applications and should not be turned off (there is a reason why it's opt-out these days, and there has been a reason why it was opted-out, but this is now obsolete).

One recent example from June 202 (and if you go through all security patches, you will find a lot more of them), this is a common threat.
https://www.cvedetails.com/vulnerability-list/vendor_id-12113/Nodejs.html
Even more recent, September 2020:
https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/

Any big application has such security holes and this is totally normal:
https://security.stackexchange.com/questions/21137/average-number-of-exploitable-bugs-per-thousand-lines-of-code

Especially with Node.js, this kind of issues are a big threat as most users install a Node version and don't update it frequently, so many binaries out there are vulnerable to publicly well known memory corruptions.

[mcollina]

Considering the releases in https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/, how would -pie increase protection for CVE-2020-8252 (see also https://hackerone.com/reports/965914 https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/#fs-realpath-native-may-cause-buffer-overflow-medium-cve-2020-8252)? (I think that's the only one memory-related, the others are HTTP).

I'm guessing @Trott @devnexen @richardlau @addaleax you'd be in favor of enabling -pie on all platforms?

[woodfairy]

Considering the releases in https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/, how would -pie increase protection for CVE-2020-8252 (see also https://hackerone.com/reports/965914 https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/#fs-realpath-native-may-cause-buffer-overflow-medium-cve-2020-8252)? (I think that's the only one memory-related, the others are HTTP).

I'm guessing @Trott @devnexen @richardlau @addaleax you'd be in favor of enabling -pie on all platforms?

Ok in the particular case for CVE-2020-8252, an exploit is very unlikely by the nature of the bug, but still is for other ones. Didn't to enough research on this one, my bad.

I personally would not necessarily enable it on Linux, as this is a production system for many users, and I can understand that 5-10% performance decrease are too much for this platform. That's my opinion on that (but I'd still be happy if it's done).

[addaleax]

We consider JS code as "trusted"

@mcollina This is not what this is about.

Considering the releases in https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/, how would -pie increase protection for CVE-2020-8252 (see also https://hackerone.com/reports/965914 https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/#fs-realpath-native-may-cause-buffer-overflow-medium-cve-2020-8252)?

Well … as @woodfairy said, this is probably not easy to exploit on its own, but I can try to turn it into an example of where ASLR would help mitigate impact: If an attacker can cause a write buffer overflow here, they can write to memory that they should not be able to write to. If they can write to memory that contains a function pointer (and possibly some arguments that are later passed to that function – that’s not an uncommon combination), they can overwrite that pointer with another value, leading to a jump to an attacker-controlled address later. If ASLR is disabled, the addresses for code in the Node.js binary itself are fixed, and very easy to jump to, making it possible to jump to an attacker-controlled function inside Node.js (which may perform privileged operations, including using functions that write data to disk). If ASLR is enabled, that makes addresses inside the Node.js binary hard to guess, and can make such attacks impractical.

I'm guessing @Trott @devnexen @richardlau @addaleax you'd be in favor of enabling -pie on all platforms?

I would be okay with that, but I feel like @woodfairy here.

[mcollina]

I see, thanks for the detailed explanation. This can be useful indeed.

I disagree with the premise that Mac OS X could "run slower" than other platforms. I'll do some measurements on a real world codebase and report back.

[mcollina]

How have you measured the 5-10% slowdown? I've run a few tests and webpack build times or http server throughput are not effected in a meaningful way. I have a Macbook Pro 13'' 2020.

[woodfairy]

How have you measured the 5-10% slowdown? I've run a few tests and webpack build times or http server throughput are not effected in a meaningful way. I have a Macbook Pro 13'' 2020.

I measured using the benchmarks in benchmark/

I have a MacBook Pro 13" 2016

[mcollina]

I measured using the benchmarks in benchmark/

Which one did you run?

Maybe is there some sort of HW/OS support that could make this less expensive?

[devnexen]

I'm guessing @Trott @devnexen @richardlau @addaleax you'd be in favor of enabling -pie on all platforms?

Would be in favor indeed.

[woodfairy]

I measured using the benchmarks in benchmark/

Which one did you run?

Maybe is there some sort of HW/OS support that could make this less expensive?

There are the results of the benchmark.

#33425 (comment)

It is possible that my hardware causes those. But I don't know it.

[mcollina]

lgtm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/34391/

[mcollina]

CI is failing somehow :/

[woodfairy]

CI is failing somehow :/

This is very odd as PIE should not affect the code. I will look into it, hopefully soon.

[addaleax]

I think there’s a good chance that all of those are flaky, pre-existing failures.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/34406/

[aduh95]

CI is green. Is this ready to land?

[github-actions]

Landed in fff25a0...8d6b74d