Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
build: enable ASLR (PIE) on OS X #35704
Conversation
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
|
Since common.gypi also affects addons: Should we be extra careful and label this semver-major? |
Probably. Does it have to be in |
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 |
|
ugh then I guess defensively |
|
@nodejs/tsc This is semver-major and so would need at least one more TSC approval. |
|
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? |
|
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. |
@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
|
ah that's why my inbox is full of alerts? |
|
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. |
|
@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. |
|
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. |
|
Does python, ruby, etc ships with this enabled? Does go, rust produce binaries with this enabled by default? |
|
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. |
Yes, and, at least on my Ubuntu machine, they also do so on Linux.
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. |
|
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. |
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.
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++. |
|
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. Any big application has such security holes and this is totally normal: 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. |
|
Considering the releases in https://nodejs.org/en/blog/vulnerability/september-2020-security-releases/, how would I'm guessing @Trott @devnexen @richardlau @addaleax you'd be in favor of enabling |
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). |
@mcollina This is not what this is about.
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 would be okay with that, but I feel like @woodfairy here. |
|
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. |
|
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 |
Which one did you run? Maybe is there some sort of HW/OS support that could make this less expensive? |
Would be in favor indeed. |
There are the results of the benchmark. It is possible that my hardware causes those. But I don't know it. |
|
lgtm |
|
CI is failing somehow :/ |
This is very odd as PIE should not affect the code. I will look into it, hopefully soon. |
|
I think there’s a good chance that all of those are flaky, pre-existing failures. |
|
CI is green. Is this ready to land? |
|
Landed in fff25a0...8d6b74d |
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 PR-URL: #35704 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
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), orvcbuild test(Windows) passes