
NPM Package Hijacking From the Hijacker's Perspective - chatmasta
https://medium.com/@nm_johnson/npm-package-hijacking-from-the-hijackers-perspective-af0c48ab9922#.9jhs5aff4
======
api
Security in a complex interdependent software ecosystem is untenable.

Period.

NodeJS/npm is in no way unique here. Apt, yum, gem, Homebrew, Docker hub, etc.
are just as bad if not worse, not to mention "git clone" followed by
"./configure" or "make." Any time you bring down code onto your machine and
execute it you are... well... bringing down code onto your machine and
executing it.

I've been increasingly thinking that this could be a very fertile area for AI
research. Security is really an AI hard problem. There is no combination of
sandboxing, permissions, auditing, formulaic static code analysis, firewall
hacks, etc. that will yield a system that is both (a) usable/convenient and
(b) secure.

Take 'npm' for instance. It's amazingly convenient but it (and all other
packagers like it) is a security nightmare. Operating securely would require
one to set up a shadow mirror of the entire NodeJS ecosystem and then have
someone ($$$$$) manually audit _every single thing in there_ that you are
going to use and _every single change_ that comes down from above. That's not
tenable for anyone but the most lavishly funded organizations, and anything
like that is universally reviled by developers since it slows them down. I've
worked in environments like that before (government), and we had people quit
because it was just "impossible to do my work."

~~~
white-flame
The real problem is that things you run have full access to anything that you
as a user have. In a more ideal security scenario, one that I've been
pondering for many years, every single program has its own sandbox to play in,
and can't see or affect your other user data. I'm sure that mobile devices are
doing very similar things.

An "Open File" dialog box would let the user see exactly what they're picking,
but just return an opaque & reusable handle to the program, meaning there's no
change to the user experience. There would be more permission requests to the
user in other circumstances, but that's the result of distrusting code that's
running on your box.

I wouldn't expect an AI to try to preempt all the problems of a black-list
style system, but rather a white-list as above would be far more manageable.

~~~
eridius
Isn't that basically what OS X app sandboxing is? Well, the results of Open
File aren't an opaque blob, but the app doesn't have permission to access
files outside its sandbox until the user uses the Open dialog, which grants
the app access to the file in question.

------
jwcrux
I'm not a JS dev, but would it be possible for a malicious actor to create a
pre/post install script that looks for packages published by the current user
and "worms" its way into those pre/post install scripts?

If this were possible, something like this could have the potential to infect
quite a few npm modules.

~~~
ENTP
The post install script can be like any other script the user can run. There's
no sandboxing so it can access anything the running user can access. So
essentially, yes, it could infect any other module in there. I believe it
could even run an "npm publish", which is pretty scary.

~~~
dineshp2
The recent NPM situation was a real eye opener for me. I never gave much
thought to the attack vectors involoving package managers.

> The post install script can be like any other script the user can run.
> There's no sandboxing so it can access anything the running user can access.

Wow. This just seems wrong that the script has such far reaching privileges.

~~~
nmjohn
Considering node.js is able to spawn subshells and execute whatever code it
wants when running, install scripts pose no additional threat to just running
the javascript.

~~~
rdancer
The changes a package install makes ought to be limited to the source files
within its subdirectory (and perhaps some precompiled binaries). I don't quite
expect it to be installing rootkits, and the principle of least privilege
dictates that it should not be allowed to.

Once the package is installed, it is already too late for a code review, or
any mitigation. A well-written worm will never be detected.

It is unexpectedly bad design (or, in case of the JavaScript community, an
expectedly bad design).

------
DCoder
See also:
[https://github.com/joaojeronimo/rimrafall](https://github.com/joaojeronimo/rimrafall)

------
amk_
One thing that bothers me about the Node community is how the first person to
implement a protocol/API/wrapper tends to name their package something like
'protocol' or 'protocol-js' instead of something like 'a-clever-
differentiable-brand-name' as is common in other software communities. That
makes it hard to distinguish an unmaintained package with tons of bugs from a
more polished version sponsored by a big-name contributor, and makes it easy -
even encourages - consumers to place unwarranted trust in packages with
legitimate-sounding names. As an example, consider if a new browser on Linux
was packaged as 'browser-linux' in the system repositories-- how many
downloads would it get?

------
supermatt
Why are modules allowed to be unpublished?

~~~
rst
A few reasons why a module might be unpublished:

1) Legal -- copyright violation in the code itself, patent infringement, full
text of a novel somehow found its way into the docs, etc.

2) Bugs or security holes, particularly if a bug is being actively exploited
in the wild.

Hopefully, neither of these comes up often, but when they do, you need for the
mechanism to be available.

------
2sk21
This is exactly what has made me extremely nervous about NPM. There is no
security oversight at all and modules running on my dev machine with my full
credentials could be uploading anything - Looks like I'll have to move node.js
development to a sterile VM.

------
tedmiston
In the Python world, you can self-host a copy of PyPI [1] (our package repo).
Though you might do it for a faster build process, this can also prevent the
"disappearing public repo" problem [2].

Is there something analogous for npm?

1:
[https://pypi.python.org/pypi/pypiserver](https://pypi.python.org/pypi/pypiserver)

2: [http://schinckel.net/2013/04/15/my-own-private-
pypi/](http://schinckel.net/2013/04/15/my-own-private-pypi/)

------
JdeBP
Duplicates
[https://news.ycombinator.com/item?id=11360242](https://news.ycombinator.com/item?id=11360242)
.

------
sschueller
Why can't we have a packages.lock like composer has? At least we can then
decide if we want to install updates and keep all environments in sync.

~~~
paulddraper
npm shrinkwrap

~~~
tedmiston
> Caveats

> If you wish to lock down the specific bytes included in a package, for
> example to have 100% confidence in being able to reproduce a deployment or
> build, then you ought to check your dependencies into source control, or
> pursue some other mechanism that can verify contents rather than versions.

[https://docs.npmjs.com/cli/shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap)

