Secure Node

[prettydiff]

Feature Request

I would like to propose Node as an official development platform within the US Army. In order for this to happen I would need Node to be a bit more locked down. Could there be a more secure subset of node so that the following features require administrative privileges?

• npm
• file system (fs, path)
• network access (net, http, https, http/2, udp)

In a secure platform Node would be available to regular users without the above features. Attempting to access those features in code without administrative access would throw an error. Using an administrative console or sudo those features would be available just the same as they are today.

[gireeshpunathil]

thanks @prettydiff for sharing the use case. the requirement looks specific to controlling three entities: npm, fs and net. However, considering that different users will wish to have a similar control on a different set of modules, it makes sense to generalize it and think about tunables that control access to the specified module. Does it sound sensible to you?

In either way, this is neither an endorsement on the feature nor a guarantee on the implementation, instead an attempt to scope it appropriately. /cc @nodejs/security for review.

[Trott]

@nodejs/security-wg

[lirantal]

hi @prettydiff, thanks for sharing with us!

can you provide more details on the actual use-case on how would node as a platform be used within that organization?

we have recently engaged in similar discussions and while there isn't yet an out of the box general solution for this, I am wondering if containerizing your applications would be a suitable solution?

[prettydiff]

@lirantal In the near future there may be a software tool developer profession within the US Army's new cyber school. Currently, tool development is a minor skill taught as a short class in the newly established 170A job and the language taught is Python. I would prefer the institutional language of the US Army cyber school to be JavaScript and/or TypeScript.

A major concern of any security sensitive organization is data exfiltration. I do have a security concern with Node in that access to the file system is unrestricted and access to the network is unrestricted. It is simple to use the fs library to write a tool to recursively walk the file system and produce a map of file system resources. It is also simple to write a short lived HTTP or UDP service to push file system artifacts via request or pushed via web sockets.

My fear is that bad actors will use these capabilities to retrieve restricted data from systems accessible over the internet or use these capabilities to consolidate sensitive resources on secure systems for later removal to bypass security in place.

The concern of #22112 is perhaps more secure and less specific in that access controls should be devised to prevent any unwarranted code execution. The goals there would certainly cover this use case, but the proposed approach needs scrutiny.

[lirantal]

Appreciate the elaborate reply.
I think that Node isn't unique in this perspective. Out of curiosity, does Python have a security policy mechanism similar to what you're describing?

Regardless, as been already noted in this thread we're still exploring what are some possible ways to handle this and you can also chime in on this issue or at least subscribe to it to follow-up: #327

[tniessen]

I do have a security concern with Node in that access to the file system is unrestricted and access to the network is unrestricted.

It is restricted by the usual OS / file system access control, and a secure system setup should have that configured properly. So I assume that this is about running untrusted code and about completely disabling access to the fs API? Or do you want precise control over which files a user can access?

[prettydiff]

@tniessen I agree that standard OS access controls, LDAP roles, and other management govern which files a user can access regardless of whether the user is accessing those files via a Node application. I also believe that network access is governed by network management primarily outside the local machine instance and possibly on the local machine instance via local firewall, HIPS, and host file definitions.

My primary concern is the combination of automated file system traversal, particularly with access to a shared enterprise file system volume, with the ease of spinning up new network services that appear to be regular internet traffic originating on the local machine from a regular application instance.

Historically applications that are authorized on military systems with these capabilities are exclusively permitted, as in a white list, after third-party code review of the application written under contract. Most such applications that I have personally encountered with these capabilities in the military are closed source apps written in Java. This is not the modern world enjoyed by Node developers who can conveniently spin up small (open-source) tools on the fly to perform all manners of automation and conveniently modify those tools as they need.

In addition to working for the military I also work at a very large bank that employs layers of security with a similar feel to the military. In the corporate world these same security concerns are managed through exposing Node only to authorized machines that operate in dedicated internal environments. These management limitations confine Node's potential to specified business requirements of the internal environments, typically as build tools and supporting applications in the creation of web applications and mock services. To create automation tools and bypass these management constraints, in all previous civilians employers as well, I have generally performed all Node tool development as a hobby that I bring back into the job as an external NPM package. Since invented here is significant in the corporate world I simply don't claim to be a tool developer as applications are better trusted if they are believed to be written by unassociated third parties.

A primary difference between the military and the corporate world is that the military owns its own infrastructure, tools, and capabilities. The military also has unique business needs that are often not considered in the corporate world, for example the differences between civilian radios and military radios that are also encrypted and frequency hop. These differences suggest that there is a greater need and potential for internal automation capabilities compared to the corporate world and that the military is only just waking up to the business need.

[mikesamuel]

@prettydiff

A major concern of any security sensitive organization is data exfiltration. I do have a security concern with Node in that access to the file system is unrestricted and access to the network is unrestricted. It is simple to use the fs library to write a tool to recursively walk the file system and produce a map of file system resources. It is also simple to write a short lived HTTP or UDP service to push file system artifacts via request or pushed via web sockets.

I've been working to address some of these problems per nodesecroadmap.

External sandboxes like nsjail are the best way to limit file-system access when neither Node user code nor the runtime need access.

If part of the node process does need access to a file things get harder.

It sounds like when you say "it is simple to use the fs library to ..." that you're worried about malicious code loaded into the runtime.

If you're worried about malicious developers, then there's no good story for single-process Node, even ignoring side-channel attacks. There are currently too many ways to access process.binding and the Node C++ code that unpacks JS values has not been hardened. Deian Stefan gave a talk titled "Finding and preventing bugs in JavaScript bindings" which is not up yet in video form about that.

If you can assume good faith on the part of developers and have separate mechanisms for source supply chain security, then the story gets better.

Module resolver hooks like those I demoed at jsconf.eu can help both prevent require from being tricked into loading arbitrary code from the file-system giving you resource integrity checks for modules.

Resolver hooks also let you identify sensitive module sets and whitelist which modules can link to them. That same jsconf talk shows that being done for child_process via module graph pruning.

---

Re leaks, boxes provide a way to communicate values from one module to another without handing the value to intermediate layers.

If you're worried about malicious code, then you have to account for Spectre which allows low-bandwidth leaks of anything in process memory. JavaScript makes no guarantees about when deallocation happens and strings are immutable, so once a secret makes it into a JavaScript string you can't bound your window of vulnerability to Spectre. Even if you do all the usual tricks to zero Buffers and account for caches, JavaScript's automatic value coercion adds another wrinkle.

The second puzzle in "Puzzling towards security" talks about ways to reason about unintentional leaks. The solutions video at the end talks about boxes though I hadn't gotten all the module-keys details in places when I recorded that.

[prettydiff]

It sounds like when you say "it is simple to use the fs library to ..." that you're worried about malicious code loaded into the runtime.

That is somewhat of an over simplification. It is certainly a lesser worry from an NPM package doing things management would not approve of or that there could be a defect in the runtime. I suspect some of that malicious code will be detectable by security mechanisms, outside of Node, already in place on the enterprise. Many of these problems will be fixed as quickly as possible once they are known in the spirit of open source software.

The more common worry from an enterprise management perspective is always the insider threat whether it is a user writing/executing powerful tools unaware of the security implications or an internal user actively seeking to undermine the organization. I could be naive, but my thinking is to reduce these risks by limiting execution of certain APIs behind privilege escalation. I am thinking in terms of a management layer that offloads some risks to authorization defined outside of Node.

Security risks will not be eliminated and expecting security perfection isn't realistic. You mentioned side channel attacks as a hard to solve problem, and I agree. There are many security problems that Node shouldn't solve as they are better solved by the OS, hardware, or other security mechanisms.

[mikesamuel]

@prettydiff

The more common worry from an enterprise management perspective is always the insider threat

There are many security problems that Node shouldn't solve as they are better solved by the OS, hardware, or other security mechanisms.

Thanks for explaining. The insider threat is an important one.
I'm not sure that it can be addressed by tweaking Node though.

My intuition is that it is not feasible to separate file read privileges from network send privileges in a single-process Node setup.

I think that the mechanisms I argued for above that assume good-faith also make it hard for an insider to plausibly denying that they intentionally bypassed security measures. That might not help much if leaks are a major concern.

[Trott]

Is there anything concretely actionable here at this time? If so, what exactly? If not, should this issue be transferred to the Security WG repo? Should it be closed?

[mikesamuel]

@Trott, I think it can transfer to security-wg.

@prettydiff
Relevant to

my thinking is to reduce these risks by limiting execution of certain APIs behind privilege escalation.

Per #409 I've got a testbed for some mitigations that include controlling what code links to sensitive APIs.

The sensitiveModules property in package.json specifies that (child_process, fs, http, process, pirates, pg, vm) are sensitive modules.

Then the sensitive module hook gets called on require.

Within Google we've used similar mechanisms to help a small appsec group ride herd on a larger group of devs.

If you run the testbed, you'll notice that it warns that jsdom is not allowed access to http. This app loads jsdom so that DOMPurify (an HTML sanitizer) can parse fragments of HTML. JSDom uses http to fetch scripts and styles over the network, but that functionality isn't needed by DOMPurify, so I didn't whitelist it. If there is some bug in DOMPurify that allows an attacker to cause a network fetch, this should block that.

[prettydiff]

@mikesamuel Thank you for your time. I will have to play around with this.

[fraxken]

👋 Hello,

Some work is currently happening here: #791

I guess it will solve some of the concerns raised by this old issue/proposal.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.