While running the npm start
command and the dev env set to development or running a special command (like npm run dev
, where dev is a special script which starts up a local development environment as specified in package.json
), which executes the devDependencies
specified in the package.json
. Of course it's up to the user in some cases to first include the required files, but there are exceptions like fake (simulated) APIs, localhost servers like used in Angular (you run it with ng serve
, which actually by default does not contain even self-signed SSL certificates) and etc. Now the real danger is that Bash/PowerShell/Batch files and Binaries could also be executed this way, which is a big yikes!
Now to the main part of the question - what possible harm could it do? Since it executes any arbitrary code ignoring the fact that the V8 (still in 2021 it's considered the most secure JavaScript engine) includes a great Sandbox for which Google put a lot of work to get secure and going in blind without any code review it could mean one of the following:
- Upload and leak your whole source code
- Destroy your source code
- Since it has filesystem access it could mess with your filesystem and possibly in theory in extension for example install rootkits
- It could sniff your local network traffic, which is usually nowadays encrypted
- It could host an Evil AP Twin
- Trojans, worms, cryptominers etc
- It could read your network activity
- It could mess with your packets, send out packets you don't want
- Mess with your certificates, forge them etc
- A malicious linter could you do the opposite of snyk.io - insert/suggest building vulnerabilities into your app and so in production making a vulnerable app/API
- In theory even damage your hardware
- Obfuscate itself to hide malicious code
- Combinations of these and more...
...and other possibilities that generally malware has... Security StackExchange is full of other suggestions how it might get abused.
There's no built-in permissions system or anything like that so the possibilities are pretty much endless apparently...
More realistic examples include: vulnerable parsers, which could read to RCEs etc, bad crypto, which can easily be "hacked" (this was present in the native library crypto and if I'm right still in crypto and there used to be warnings in the documentation to not use some of the methods), see history of vulnerabilities below.
Now, what about local development servers? Can't they be crawled by bots from the outside a.k.a. World Wide Web? Well it depends on your firewall, router and your local server implementation. Usually local dev servers use a localhost interface (as done in Windows) or a 127.0.0.1 local IP, which is accessible only inside the LAN. I have seen some amateur made local dev servers using 0.0.0.0 interface on Unix, which is a big yikes if you're open to the World Wild Web, meaning your APIs can get bruteforced and as all complex APIs (again it depends on your API) open up a door for malware to your machine (I am of course implying that the API gets discovered and it has write and execution (usually via vulnerabilities like LFI etc) possibilities).
How hard is it to review JavaScript in modules? Well, nowadays the obfuscation and minimization tools are quite advanced and there are companies specialized in this field and they supposedly promise that your JavaScript will not be reverse-engineered with medium effort. If you want a good example I always point to a popular xkcd comic, which contains obfuscated JavaScript for a right-click menu https://xkcd.com/1975/
Also, there's a danger of spawning of malicious service workers and other shenanigans.
If you want maximum security in development and production and want to use JavaScript I would recommend looking into Deno, which is actually developed including the same Ryan Dahl who initially developed Node.js and thought to himself "hey, I would do better". He made a video called "10 things I regret about Node.js". The link for the video is here: https://www.youtube.com/watch?v=M3BM9TB-8yA
As from approx. 6:13 in the video the developer admits that the Node.js main event loop has access to all sorts of system calls. Since Node.js is usually run as admin/root this could lead to all the possibilities mentioned above.
If you want to see a more secure infrastructure please look in the video at the timestamp 18:59.
Apparently npm audit
does no actual code analysis and only shows reported vulnerabilities, but that doesn't solve any of the problems. GitHub security bots and Snyk.io bots on the other hand do have the possibility of detecting such vulnerabilities as long as the modules are not obfuscated.
What I find extremely likely to happen is that there are certainly no limits set on the following actions:
- Hijacking
require()
calls, like it's done by well meant software like babel, TypeScript components etc
- Surprisingly, it can override core modules, literally.
I'm a hardcore coder, what can I do?
I'm glad you asked. Node.js API (or core modules, whatever you wanna call it) contains a VM API. For more information look into this documentation link . You could so get the features of V8 Sandbox for your code, but as in the link it's stated the maintainers of Node.js recommend AGAINST running untrusted code inside of it.
History of vulnerabilities in dev packages
ID: CVE-2022-23812
Title: Arbitrary file overwrite vulnerability in the Node-IPC NPM package
Description: T The package node-ipc versions 10.1.1 and 10.1.2 are vulnerable to embedded malicious code that was introduced by the maintainer. The malicious code was intended to overwrite arbitrary files depending on the geolocation of the user's IP address. The maintainer removed the malicious code in version 10.1.3.
CVSS v3.1 Base Score: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
general hkcert advice about third party dependencies
not to mention the usual typosquatting