Hacker News new | ask | show | jobs
by andrewaylett 3742 days ago
Take Maven as an example: it's not vulnerable to this attack for several reasons:

1) No install scripts. Fetching a dependency in NPM will execute arbitrary code. Fetching a dependency in Maven doesn't execute any code from the dependency. Obviously when I run my project, I'm expecting to call code in that dependency, so this is a mitigation not a complete fix. But that does lead on to the next point.

Corollary: You have to change the code in my project to spread the worm, not just add a new dependency, otherwise your worm code won't get executed. This is probably a bit more tricky to get right.

2a) Code deployed internally from CI servers, not local machines. It's got to be code-reviewed before it gets pushed to my employer's package repository.

2b) Code needs to be signed before being uploaded to Maven Central. I'm not going to start typing my GPG key into random unexpected prompts.

Malicious code is still a possibility, but the scope for a worm is much less.
1 comments
STRML 3742 days ago
Unfortunately, it's not as simple as disabling `postinstall` hooks. In dev,, especially, the Node process likely runs as the same user as the one who publishes packages. There is nothing stopping the code from spawning `npm` and publishing a malicious project as soon as it is require()d. And of course, you're requiring it at some point, otherwise why would you install it?

A better fix to this issue is to require publishers to enter a two-factor token, to email them to confirm publishing, or the like.

Yeah, it makes everyone a bit uneasy with how much trust is involved in the ecosystem. Is there a better solution?

link
andrewaylett 3741 days ago
Rather than 2FA, Maven requiring a GPG signature provides that extra security for me. Neither are infallible -- malware could infect your system sufficiently to intercept your next legitimate authentication.

Also, disabling install hooks in NPM would make things really difficult for packages that rely on native code as they've traditionally been compiled on install. I consider that an anti-pattern, but it's one that's unlikely to be removed any time soon.

link