src: add WDAC integration (Windows) #54364
Conversation
|
Review requested:
|
nodejs-github-bot
added
lib / src
RafaelGSS
added
semver-minor
|
Can you run the formatter? |
|
I also want to add - this is meant to facilitate discussion regarding the general implementation. I'm not very familiar with the various module loaders and ways which code can be read off disk and executed. I assume there are gaps in my implementation and I would appreciate any expertise in the area to close them. Thanks! |
|
@nodejs/platform-windows |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #54364 +/- ##
========================================
Coverage 90.22% 90.23%
========================================
Files 630 631 +1
Lines 185055 185156 +101
Branches 36216 36230 +14
========================================
+ Hits 166975 167069 +94
- Misses 11042 11061 +19
+ Partials 7038 7026 -12
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
We've discussed on the security-wg and the next steps are:
- Creating documentation
- Improving the test coverage
Then we can go the a proper code review. Meanwhile, I'm tagging @nodejs/tsc for awareness.
This is a Windows specific feature that will enabled by a node key in Windows system dictionary. So, it shouldn't be considered a semver-major or a specific Node.js API.
Currently, Windows should be the only environment that makes those checks available via API. We are still evaluating the status of OSX and Linux support for that. However, it's fair to assume this PR will only implement such guarantees for Windows users.
I recommend watching our meeting as we've discussed the usage and how this is turned-on in Windows systems (https://www.youtube.com/watch?v=w4zzH-otKNI)
|
FYI, we are working on a similar feature for Linux. The goal is the same but the implementation and API are different. Linux already provides access control systems and this new feature (previously open+O_MAYEXEC, now execveat+AT_CHECK) is the missing piece to control script execution the same way other kind of execution can already be controlled. This article gives a good overview: https://lwn.net/Articles/982085/ I plan to send a new patch series in a few weeks. Please let me know what you think. |
rdw-msft
force-pushed
the
wldp-integration
branch
from
7cfafd5 to
e8e5e7a
Compare
rdw-msft
force-pushed
the
wldp-integration
branch
from
e8e5e7a to
18b9645
Compare
|
Hey @RafaelGSS , I've added more documentation about code integrity mode. Please let me know if it looks adequate, or if you'd like me to explain more. I also added doc/api/wdac-manifest.xml. This is the manifest we spoke about in the last meeting I attended. It declares the WDAC Application settings that NodeJS will query for. It should be hosted in an accessible place so when system admins author their Windows Code Integrity policy they know what settings are available to them, and it also adds some type-checking for the policy writer. I'll plan on attending the next security WG meeting to discuss in more detail if needed. Thanks |
doc/api/wdac-manifest.xml
Outdated
| <AppManifest Id="NodeJS" xmlns="urn:schemas-microsoft-com:windows-defender-application-control"> | ||
| <SettingDefinition Name="EnforceCodeIntegrity" Type="Boolean" IgnoreAuditPolicies="false"/> | ||
| <SettingDefinition Name="DisableInterpretiveMode" Type="Boolean" IgnoreAuditPolicies="false"/> | ||
| </AppManifest> |
There was a problem hiding this comment.
| </AppManifest> | |
| </AppManifest> | |
src/node_code_integrity.cc
Outdated
| static void IsFileTrustedBySystemCodeIntegrityPolicy( | ||
| const FunctionCallbackInfo<Value>& args) { | ||
| args.GetReturnValue().Set(true); | ||
| } |
There was a problem hiding this comment.
These could probably just be implemented in JavaScript so avoid the extraneous JS->C++ boundary call.
src/node_code_integrity.h
Outdated
|
|
||
| #include <Windows.h> | ||
|
|
||
| // {0xb5367df1,0xcbac,0x11cf,{0x95,0xca,0x00,0x80,0x5f,0x48,0xa1,0x92}} |
There was a problem hiding this comment.
It's not clear what this comment is.
src/node_code_integrity.h
Outdated
| #ifndef SRC_NODE_CODE_INTEGRITY_H_ | ||
| #define SRC_NODE_CODE_INTEGRITY_H_ | ||
|
|
||
| #ifdef _WIN32 |
There was a problem hiding this comment.
Given that this is Windows only, I would generally prefer that this entire internal binding only be compiled on windows, with the non-functional stubs implemented solely in javascript on the other platforms.
Thanks for running the job! I'm going to be on vacation for a week, but I'll look into this as soon as I'm back |
doc/api/code_integrity.md
Outdated
| @@ -0,0 +1,133 @@ | |||
| # Code Integrity | |||
|
|
|||
| <!--introduced_in=v24.0.0--> | |||
There was a problem hiding this comment.
I think due to the time frame, it will be unlikely to land on v24.0.0. Also I consider it as semver-minor, so it can land in a later release.
I could be wrong, since I'm not familiar with Jenkins, but it looks like that this test is failing on other CI runs, so I don't think it's related to my changes (for example, this test failed on the latest successful Windows build https://ci.nodejs.org/job/node-test-binary-windows-js-suites/lastCompletedBuild/testReport/). I ran the test suite locally, and it passed this test. I traced through the code a bit, and I think if this was related to a code-integrity change a different error would be thrown. |
rdw-msft
force-pushed
the
wldp-integration
branch
from
56aad2c to
44cbb21
Compare
github-actions
bot
removed
the
request-ci
|
I'm adding a I'm also tagging @nodejs/tsc for review. Please consider that we have precedence to features that are OS specific (we have recently landed #56496 for Unix systems). Considering this is an opt-in feature and experimental, it would be great to see the impact of this security mechanism on developers. Thanks @rdw-msft for the persistence on working on this. cc: @nodejs/security-wg |
RafaelGSS
added
the
notable-change
|
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
Awesome! Thanks for helping me with these changes |
Add calls to Windows Defender Application Control to enforce integrity of .js, .json, .node files.
rdw-msft
force-pushed
the
wldp-integration
branch
from
44cbb21 to
4c5a59d
Compare
RafaelGSS
added
commit-queue-squash
|
This seems to only work with the CommonJS loader. Should that limitation be at least documented? |
The intention is for this to work on all code loaded and executed from local files (except for cases like reading a file and calling Can you point me to the other loader(s) you have in mind? |
|
getSource and getSourceSync in https://github.com/nodejs/node/blob/main/lib/internal/modules/esm/load.js There may be other places still. |
Add calls to Windows Defender Application Control to enforce integrity of .js, .json, .node files.
Motivation
In the past I've spoken to @RafaelGSS and the Node security work group about code integrity. We feel like it's an important defense in depth feature and the removal of the --experimental-policy feature gives us room to use OS-level code integrity features. This is a first pass at a CI implementation that cooperates with the OS.
These additions add an additional layer of defense against malicious code execution on a system that is enforcing code integrity. Code Integrity enforcement mitigates the risk of malicious code modifications after signing-time. For example, they can prevent an arbitrary file-write vulnerability from turning into an RCE. These additional checks are only made if the OS in code integrity enforcement mode and has explicitly set a configuration value in their code integrity policy to have Node enforce CI.
Windows Defender Application Control (WDAC)
Official documentation: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview
WDAC is the Windows code integrity subsystem. It enforces code integrity using digital signatures. This is straightforward for DLLs and EXEs, since they're loaded using well known entry points in the OS. However, dynamic runtimes (interpreters like Node.js or Python) make it difficult to determine whether a file being read will be executed. In order to assist dynamic runtimes, WDAC provides an interface for runtimes to call with the code they intent to execute, and WDAC will determine if the runtime is allowed to execute the code based off signature information. WDAC (wldp.dll) exposes various methods for runtimes to ask the OS questions about the code integrity policy on the system. These changes leverage three interfaces
WldpCanExecuteFile,WldpGetApplicationSettingBoolean, andWldpQuerySecurityPolicy.WldpCanExecuteFile- given a file handle, determines if the file is allowed to be executed from WDAC policy.WldpGetApplicationSettingBoolean- Queries WDAC policy for an application-defined setting with a boolean value. This can be thought of as a more secure setting store.WldpQuerySecurityPolicy- WdlpGetApplicationSettingBoolean is not available on all versions of Windows, so this method provides fallback behavior to query WDAC policy settings.High-level implementation
At startup, Node will query WDAC policy to see if it should enter integrity enforcement mode. If the policy provider
Node.jshas set the policy settingEnforceCodeIntegrityto TRUE, then Node will callWldpCanExecuteFilewhen a .js, .json, or .node file is loaded usingrequire. If this setting is not enabled, the call to WldpCanExecuteFile will not be made and execution will continue as normal.Additionally, if
EnforceCodeIntegrityis set to TRUE, we disable features that allow arbitrary code from being executed by Node (e.g. the "-e" command line option and the REPL) when the system is enforcing code integrity.Signing files
Signatures are stored in catalog file,
.cat. This catalog file can be thought of as a collection of filenames and their associated hashes. A Node application author can generate a catalog using the Powershell commandNew-FileCatalogdocumentation.PS> New-FileCatalog -CatalogFilePath ./MyApplicationCatalog.cat -Path ./MyApplicationRelease/The catalog then can be signed with a certificate trusted by WDAC policy using Powershell with
Set-AuthenticodeSignaturedocumentation orsigntool.exeThe signed catalog can then be installed on the system MyApplication is being deployed to.
Other Questions
What about Linux?
At the moment, there is no unified code integrity subsystem that provides similar cooperative interfaces for interpreters on Linux. There are proposals in-flight and we're tracking this work and hope to keep the implementation as similar as possible across OSs.
Notable Change
Adding OS code integrity integration to mitigate unintended code execution. This feature is not enabled by default and must be opted into (see code_integrity.md for more information). When this feature is enabled, Node.js restricts loading of JavaScript modules to only those with signatures trusted by OS code integrity policy.