src: add WDAC integration (Windows) #54364

rdw-msft · 2024-08-14T00:35:14Z

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, and WldpQuerySecurityPolicy.

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.js has set the policy setting EnforceCodeIntegrity to TRUE, then Node will call WldpCanExecuteFile when a .js, .json, or .node file is loaded using require. If this setting is not enabled, the call to WldpCanExecuteFile will not be made and execution will continue as normal.

Additionally, if EnforceCodeIntegrity is 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 command New-FileCatalog documentation.

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-AuthenticodeSignature documentation or signtool.exe

The signed catalog can then be installed on the system MyApplication is being deployed to.

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.

nodejs-github-bot · 2024-08-14T00:35:18Z

Review requested:

@nodejs/gyp
@nodejs/loaders

anonrig · 2024-08-14T01:21:26Z

Can you run the formatter?

rdw-msft · 2024-08-14T01:42:40Z

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!

targos · 2024-08-14T06:47:59Z

@nodejs/platform-windows

lib/internal/modules/cjs/loader.js

codecov · 2024-08-19T20:25:17Z

Codecov Report

Attention: Patch coverage is 86.84211% with 15 lines in your changes missing coverage. Please review.

Project coverage is 90.22%. Comparing base (9aa57bf) to head (873bebe).
Report is 83 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/code_integrity.js	86.95%	9 Missing ⚠️
lib/internal/modules/esm/load.js	76.92%	3 Missing ⚠️
lib/internal/modules/cjs/loader.js	88.23%	2 Missing ⚠️
lib/internal/main/eval_string.js	90.90%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #54364      +/-   ##
==========================================
- Coverage   90.24%   90.22%   -0.03%     
==========================================
  Files         630      631       +1     
  Lines      184990   185405     +415     
  Branches    36216    36348     +132     
==========================================
+ Hits       166948   167281     +333     
- Misses      11003    11029      +26     
- Partials     7039     7095      +56

Files with missing lines	Coverage Δ
lib/internal/errors.js	`97.48% <100.00%> (+<0.01%)`	⬆️
src/node_binding.cc	`82.67% <ø> (ø)`
src/node_external_reference.h	`100.00% <ø> (ø)`
lib/internal/main/eval_string.js	`80.89% <90.90%> (+1.41%)`	⬆️
lib/internal/modules/cjs/loader.js	`98.04% <88.23%> (-0.23%)`	⬇️
lib/internal/modules/esm/load.js	`91.12% <76.92%> (-0.83%)`	⬇️
lib/internal/code_integrity.js	`86.95% <86.95%> (ø)`

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

RafaelGSS

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)

l0kod · 2024-09-11T14:24:05Z

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.

l0kod · 2024-09-11T15:33:16Z

Cc @tiran, @zooba

rdw-msft · 2024-10-29T17:30:55Z

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

jasnell · 2024-11-05T23:28:41Z

doc/api/wdac-manifest.xml

+<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>


Suggested change

</AppManifest>

</AppManifest>

lib/internal/code_integrity.js

jasnell · 2024-11-05T23:33:01Z

src/node_code_integrity.cc

+static void IsFileTrustedBySystemCodeIntegrityPolicy(
+  const FunctionCallbackInfo<Value>& args) {
+    args.GetReturnValue().Set(true);
+}


These could probably just be implemented in JavaScript so avoid the extraneous JS->C++ boundary call.

jasnell · 2024-11-05T23:33:34Z

src/node_code_integrity.h

+
+#include <Windows.h>
+
+// {0xb5367df1,0xcbac,0x11cf,{0x95,0xca,0x00,0x80,0x5f,0x48,0xa1,0x92}}


It's not clear what this comment is.

src/node_code_integrity.h

jasnell · 2024-11-05T23:35:47Z

src/node_code_integrity.h

+#ifndef SRC_NODE_CODE_INTEGRITY_H_
+#define SRC_NODE_CODE_INTEGRITY_H_
+
+#ifdef _WIN32


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.

github-actions · 2025-04-07T12:57:48Z

Failed to start CI

   ⚠  Commits were pushed since the last approving review:
   ⚠  - src: add WDAC integration (Windows)
   ⚠  - add typings. fix version number
   ⚠  - add integrity checks to esm loader
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/14309779253

nodejs-github-bot · 2025-04-07T13:15:27Z

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

rdw-msft · 2025-04-08T17:34:40Z

getSource and getSourceSync in https://github.com/nodejs/node/blob/main/lib/internal/modules/esm/load.js

There may be other places still.

I've added integrity checks to the ESM Loader in these places.

This feature is still in active development, and I can add integrity checks to any other paths that load and execute Javascript as they are discovered. I looked over the old code integrity feature that has since been removed (policy manifests), and it looks like it only covered these two loaders as well.

rdw-msft · 2025-04-10T14:21:49Z

I have some basic tests for the ESM loader, but I'd like to get some opinions on if there's a better way to more thoroughly cover "import" behavior to make sure all branches that load code from a local file go through this integrity check.

At the moment, I have two tests - one that checks if a simple JS file loads without error when the file passes integrity checks, and one that checks if import throws an error if the file does not pass integrity checks. These test methods just call "import" on a .js file, and the call to the OS integrity verification function is mocked to return the expected "pass" or "not pass" result.

RafaelGSS · 2025-04-11T14:31:01Z

cc: @nodejs/loaders

mhdawson · 2025-04-15T15:31:01Z

have @anonrig changes been incorporated yet. Waiting on that to go through the changes.

github-actions · 2025-04-15T17:04:42Z

Failed to start CI

   ⚠  Commits were pushed since the last approving review:
   ⚠  - src: add WDAC integration (Windows)
   ⚠  - add typings. fix version number
   ⚠  - add integrity checks to esm loader
   ⚠  - fix esm code integrity tests
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/14475195356

RafaelGSS · 2025-04-15T17:22:06Z

As discussed in the last sec wg meeting, if we land it, let's do it on the 'CURRENT' release line first, and see the adoption and feedback before porting it to an active LTS.

nodejs-github-bot · 2025-04-15T17:28:15Z

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

rdw-msft · 2025-04-15T18:04:01Z

have @anonrig changes been incorporated yet. Waiting on that to go through the changes.

Yes. The comment recommended adding a TS typing file. I did that, but I think due to some commit squashing, I can't actually pull up their comment to resolve it anymore.

anonrig · 2025-04-15T18:05:58Z

lib/internal/code_integrity.js

+function isInteractiveModeDisabled() {
+  if (!isWindows) {
+    return false;
+  }
+  return isInteractiveModeDisabledInternal();


this adds an additional item to the stack trace whenever this function is called. we should not call this method on non-windows to avoid polluting the stack trace.

Also, can't this method be cached?

anonrig · 2025-04-15T18:06:18Z

lib/internal/code_integrity.js

+// Binding stub for non-Windows platforms
+let binding = {
+  isFileTrustedBySystemCodeIntegrityPolicy: () => true,
+  isInteractiveModeDisabledInternal: () => false,
+  isSystemEnforcingCodeIntegrity: () => false,
+};
+// Load the actual binding if on Windows
+if (isWindows) {
+  binding = internalBinding('code_integrity');
+}


IMHO: We shouldn't even call this file or any of the methods for non-windows environments.

anonrig · 2025-04-15T18:07:00Z

lib/internal/main/eval_string.js

+const ci = require('internal/code_integrity');
+if (ci.isInteractiveModeDisabled()) {
+  throw new ERR_CODE_INTEGRITY_BLOCKED('"eval"');
+}


This should be surrounded by isWindows check and we shouldn't even require this file for non-windows environments

anonrig · 2025-04-15T18:07:24Z

lib/internal/modules/cjs/loader.js

+    const isAllowedToExecute = ci.isAllowedToExecuteFile(filename);
+    if (!isAllowedToExecute) {
+      throw new ERR_CODE_INTEGRITY_VIOLATION(filename);
+    }


This shouldn't be executed for non-windows environments.

anonrig · 2025-04-15T18:07:33Z

lib/internal/modules/cjs/loader.js

@@ -1878,6 +1891,7 @@ function getRequireESMError(mod, pkg, content, filename) {
 * @param {string} filename The file path of the module
 */
 Module._extensions['.js'] = function(module, filename) {
+


These unnecessary changes needs to be removed

anonrig · 2025-04-15T18:19:29Z

typings/internalBinding/code_integrity.d.ts

@@ -0,0 +1,6 @@
+export interface CodeIntegrityBinding {
+    isAllowedToExecuteFile(filePath: string) : boolean;


The indentation is wrong.

Suggested change

isAllowedToExecuteFile(filePath: string) : boolean;

isAllowedToExecuteFile(filePath: string) : boolean;

anonrig · 2025-04-15T18:19:54Z

typings/internalBinding/code_integrity.d.ts

+    isFileTrustedBySystemCodeIntegrityPolicy(filePath: string) : boolean;
+    isInteractiveModeDisabled() : boolean;
+    isSystemEnforcingCodeIntegrity() : boolean;
+}


In order for this to work, typings/global.d.ts file need to import this module...

anonrig · 2025-04-15T18:20:20Z

src/node_code_integrity.cc

+  per_process::isWldpInitialized = true;
+}
+
+static void IsFileTrustedBySystemCodeIntegrityPolicy(


Can you add a comment to each one of these method explaining what they do?

anonrig · 2025-04-15T18:20:50Z

src/node_code_integrity.cc

+static PCWSTR DISABLE_INTERPRETIVE_MODE_SETTING_NAME =
+    L"DisableInteractiveMode";
+
+void InitWldp(Environment* env) {


Since the method names are not easily readable, it is extremely hard to understand what this method does. Can you add a comment explaining what this method do, and how it does what it does?

anonrig · 2025-04-15T18:21:09Z

src/node_code_integrity.cc

+      LoadLibraryExA("wldp.dll", nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);
+
+  if (wldp_module == nullptr) {
+    return env->ThrowError("Unable to load wldp.dll");


This error needs to contain a "code" property.

aduh95 · 2025-04-15T19:41:25Z

I have some basic tests for the ESM loader, but I'd like to get some opinions on if there's a better way to more thoroughly cover "import" behavior to make sure all branches that load code from a local file go through this integrity check.

I know there have been some discussions in the past for having a centralized way for all FS interactions for internal APIs to help for such cases (/cc @arcanis)

nodejs-github-bot added lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Aug 14, 2024

RafaelGSS added semver-minor PRs that contain new features and should be released in the next minor version. security-wg-agenda labels Aug 14, 2024

mcollina reviewed Aug 14, 2024

View reviewed changes

lib/internal/modules/cjs/loader.js Outdated Show resolved Hide resolved

rdw-msft mentioned this pull request Aug 21, 2024

Discuss WDAC (code integrity on Windows) nodejs/security-wg#1364

Open

mhdawson mentioned this pull request Aug 26, 2024

Node.js Security team Meeting 2024-08-29 nodejs/security-wg#1365

Closed

RafaelGSS requested changes Aug 29, 2024

View reviewed changes

mhdawson mentioned this pull request Sep 9, 2024

Node.js Security team Meeting 2024-09-12 nodejs/security-wg#1375

Closed

mhdawson mentioned this pull request Sep 23, 2024

Node.js Security team Meeting 2024-09-26 nodejs/security-wg#1382

Closed

l0kod mentioned this pull request Sep 27, 2024

Script execution control on Linux nodejs/security-wg#1388

Open

mhdawson mentioned this pull request Oct 8, 2024

Node.js Security team Meeting 2024-10-10 nodejs/security-wg#1389

Closed

rdw-msft force-pushed the wldp-integration branch from 7cfafd5 to e8e5e7a Compare October 10, 2024 17:16

rdw-msft force-pushed the wldp-integration branch from e8e5e7a to 18b9645 Compare October 29, 2024 17:26

mhdawson mentioned this pull request Nov 4, 2024

Node.js Security team Meeting 2024-11-07 nodejs/security-wg#1398

Closed

jasnell reviewed Nov 5, 2024

View reviewed changes

doc/api/wdac-manifest.xml Show resolved Hide resolved

jasnell reviewed Nov 5, 2024

View reviewed changes

lib/internal/code_integrity.js Show resolved Hide resolved

jasnell reviewed Nov 5, 2024

View reviewed changes

src/node_code_integrity.h Show resolved Hide resolved

jasnell reviewed Nov 5, 2024

View reviewed changes

github-actions bot added the request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. label Apr 7, 2025

RafaelGSS approved these changes Apr 7, 2025

View reviewed changes

RafaelGSS added request-ci Add this label to start a Jenkins CI on a PR. and removed request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. labels Apr 7, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 7, 2025

fix esm code integrity tests

873bebe

RafaelGSS added the request-ci Add this label to start a Jenkins CI on a PR. label Apr 15, 2025

github-actions bot added request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. and removed request-ci Add this label to start a Jenkins CI on a PR. labels Apr 15, 2025

RafaelGSS approved these changes Apr 15, 2025

View reviewed changes

RafaelGSS added request-ci Add this label to start a Jenkins CI on a PR. and removed request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. labels Apr 15, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 15, 2025

anonrig requested changes Apr 15, 2025

View reviewed changes

mhdawson mentioned this pull request Apr 21, 2025

Node.js Security team Meeting 2025-04-24 nodejs/security-wg#1471

Open


		#include <Windows.h>

		// {0xb5367df1,0xcbac,0x11cf,{0x95,0xca,0x00,0x80,0x5f,0x48,0xa1,0x92}}

		@@ -0,0 +1,6 @@
		export interface CodeIntegrityBinding {
		isAllowedToExecuteFile(filePath: string) : boolean;

src: add WDAC integration (Windows) #54364

Are you sure you want to change the base?

src: add WDAC integration (Windows) #54364

Conversation

rdw-msft commented Aug 14, 2024 • edited Loading

Motivation

Windows Defender Application Control (WDAC)

High-level implementation

Signing files

Other Questions

Notable Change

nodejs-github-bot commented Aug 14, 2024

anonrig commented Aug 14, 2024

rdw-msft commented Aug 14, 2024

targos commented Aug 14, 2024

codecov bot commented Aug 19, 2024 • edited Loading

Codecov Report

RafaelGSS left a comment

Choose a reason for hiding this comment

l0kod commented Sep 11, 2024

l0kod commented Sep 11, 2024

rdw-msft commented Oct 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Apr 7, 2025

nodejs-github-bot commented Apr 7, 2025

rdw-msft commented Apr 8, 2025

rdw-msft commented Apr 10, 2025

RafaelGSS commented Apr 11, 2025

mhdawson commented Apr 15, 2025

github-actions bot commented Apr 15, 2025

RafaelGSS commented Apr 15, 2025

nodejs-github-bot commented Apr 15, 2025

rdw-msft commented Apr 15, 2025

anonrig Apr 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduh95 commented Apr 15, 2025

rdw-msft commented Aug 14, 2024 •

edited

Loading

codecov bot commented Aug 19, 2024 •

edited

Loading

anonrig Apr 15, 2025 •

edited

Loading