Does NPM use any automatic scanners? Just scanning for eval/new Function/base64 and other tokens often used by malware, and requiring a manual review, could already help.

Also package manager should not run scripts.

▲

amiga386 5 hours ago | parent | next [-]

Static scanning won't help. You can write this["eval"]() instead of eval(), therefore you can write this["e" + "v" + "a" + "l"](), and you can substitute (!![]+[])[!+[]+!+[]+!+[]] for "e", (![]+[])[+!+[]] for "a" (and so on: https://jsfuck.com/)

In this Turing-equivalent world, you can only know what actually executes (e.g. eval, fetch) by actually executing all code in the package and then see what functions got executed. Then the problem is the same as virus analysis; the virus can be written to only act under certain conditions, it will probe (e.g. look at what intepreter fingerprints, get the time of day, try to look at innocuous places in filesystem or network, measure network connection times, etc), so that it can determine it is in a VM being scanned, and go dormant for that time.

So the only thing that actually works is if node and other JS evaluators have a perfect sandbox, where nothing in a module is allowed (no network, no filesystem) except to explicit locations declared in the module's manifest, and this is perfectly tracked by the language, so if the module hands back a function for some other code to run, that function doesn't inherit the other code's network/fs access permissions. This means that, if a location is not declared, the code can't get to it at scanning time nor install time nor any time in the future.

This still leaves open the door for things like a module defining GetGoogleAnalyticsURL(params) that occasionally returns "https://badsite.com/copyandredirect?ga=...", to get some other module to eventually make a credential-exfiltrating network call, even if it's banned from making it directly or indirectly...

▲

codedokode 3 hours ago | parent | next [-]

Well, writing obfuscated code like ["e" + "v" + "a" + "l"]() is already a huge red flag for sending the package to manual review. While it might be impossible to detect all methods of obfuscation, we could start with known methods.

Also, detecting obfuscated code sounds like an interesting and challenging task.

▲

phendrenad2 4 hours ago | parent | prev [-]

There's always some mathematician who tries to prove that locks on your doors "won't help" because the universe is infinite. Narrator: it is not

▲

amiga386 4 hours ago | parent | next [-]

Deciding to put your resources into something that only a really stupid criminal would be caught by gives you a false sense of security.

Literally scanning for just "eval(" is entirely insufficient. You have to execute the code. Therefore you have to demand module authors describe how to execute code, e.g. provide a test suite, which is invoked by the scanner, and require the tests to exercise all lines of code. Provide facilities to control the behaviour of functions outside the module so that this is feasible.

This is a lot of work, so nobody wants to do it, so they palm you off with the laziest possible solution - such as literally checking for "eval(" text in the code - which then catches zero malware authors and wastes resources providing help to developers caught as a false positive, meanwhile the malware attacks continue unabated because no effective mechanism to stop them has been put in place.

Reminds me of the fraudster who sold fake bomb detectors to people who had a real need to stop bomb attacks. His detectors stopped zero bomb attacks. https://www.bbc.co.uk/news/uk-29459896

	▲	meesles 3 hours ago \| parent \| next [-]
		> Deciding to put your resources into something that only a really stupid criminal would be caught by gives you a false sense of security. Interestingly enough, this is the premise for a lot of security in the physical world. Broken windows theory, door locks as a form of security in the first place, crimes of opportunity, etc. But one should consider that in tech, the barrier to entry is a little higher and so maybe there are less 'dumb' criminals (or they don't get very far).
	▲	seethishat 4 hours ago \| parent \| prev [-]
		Which brings up a good point... is any company doing dynamic evaluation of the package updates to see what they are actually doing?

▲

venturecruelty 8 minutes ago | parent | prev [-]

"Hey, we've figured out how to detect security vulnerabilities! We just need to solve the Halting Problem!"

▲

tmvnty 5 hours ago | parent | prev [-]

Not aware of any NPM native ways but here are few community tools:

- https://socket.dev/blog/introducing-socket-firewall - https://github.com/lirantal/npq - https://bun.com/docs/pm/security-scanner-api

source: https://github.com/bodadotsh/npm-security-best-practices?tab...