
Malicious crossenv package on npm - phpnode
https://twitter.com/o_cee/status/892306836199800836
======
wolfgang42
This attack has been previously described in the paper "Typosquatting package
managers":

Paper:
[http://incolumitas.com/data/thesis.pdf](http://incolumitas.com/data/thesis.pdf)

Blog post: [http://incolumitas.com/2016/06/08/typosquatting-package-
mana...](http://incolumitas.com/2016/06/08/typosquatting-package-managers/)

Discussion:
[https://news.ycombinator.com/item?id=11862217](https://news.ycombinator.com/item?id=11862217)
[https://www.reddit.com/r/netsec/comments/4n4w2h/](https://www.reddit.com/r/netsec/comments/4n4w2h/)

The paper also discusses possible mitigation measures, including prohibiting
registering new packages within a certain Levenshtein distance of existing
packages and using additional namespacing.

~~~
hueving
Not really different from any other typo-squatting (e.g. domains).

~~~
db48x
Except that in this case you're installing software on your computer, not just
visiting a webpage.

~~~
boramalper
You might also be downloading the software from a webpage. ;)

~~~
pilif
That would still be a two-step process (downloading from the browser and then
manually executing it).

`npm install` runs code as part of the initial step.

Also, `npm install foo` will of course not just run code from `foo` but from
all its dependencies and their dependencies dependencies as well.

------
iamakulov
For everyone, here’s a one-liner to check your dependency tree:

    
    
        npm ls | grep -E "babelcli|crossenv|cross-env.js|d3.js|fabric-js|ffmepg|gruntcli|http-proxy.js|jquery.js|mariadb|mongose|mssql.js|mssql-node|mysqljs|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv.js|openssl.js|proxy.js|shadowsock|smb|sqlite.js|sqliter|sqlserver|tkinter"
    

(More details: [https://iamakulov.com/notes/npm-malicious-
packages/](https://iamakulov.com/notes/npm-malicious-packages/))

~~~
ThrustVectoring
There's a minor regex error in the one-liner: not escaping the dot, which
matches any character. Fortunately that won't cause any false negatives, and
will only incorrectly match weird things like fabric9js

Fixed:

    
    
        npm ls | grep -E "babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery.js|mariadb|mongose|mssql\.js|mssql-node|mysqljs|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer\.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv\.js|openssl\.js|proxy\.js|shadowsock|smb|sqlite\.js|sqliter|sqlserver|tkinter"

~~~
hiendv
I would add a "@"

    
    
      npm ls | grep -E '(babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery\.js|mariadb|mongose|mssql\.js|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer\.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv\.js|openssl\.js|proxy\.js|shadowsock|smb|sqlite\.js|sqliter|sqlserver|tkinter)@'

~~~
pintxo
Or to check all your npm modules within a directory:

    
    
      grep -r -i --include package.json -E '(babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery\.js|mariadb|mongose|mssql\.js|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer\.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv\.js|openssl\.js|proxy\.js|shadowsock|smb|sqlite\.js|sqliter|sqlserver|tkinter)@'

------
devwastaken
This is something I've always been concerned about with the node/NPM
environment. Any project, even the smallest ones, have hundreds of
dependencies. All it takes is some small lines of rogue code, and your entire
project is vulnerable. Especially in JS, where you can do network requests and
various critical actions all in one line of code.

~~~
colejohnson66
The `left-pad` debacle a year ago[0] should've served as a wake up call to
people writing projects with hundreds of dependencies.

[0]: [http://left-pad.io](http://left-pad.io)

~~~
doingmyting
It's next to impossible for the average team to avoid hundreds of dependencies
as their project grows though. You could write your own everything, but then
what's the benefit of the node ecosystem?

Edit: spelling

~~~
jjnoakes
I wish the node ecosystem would learn from more mature ones.

I would like to see a curated set of popular libraries that are stabilized and
blessed, and a core group that handles security updates and upgrading packages
in the blessed set.

~~~
pfooti
who gets paid to support that ecosystem, and who does the paying? as a simple
example, I use the hapi.js server framework (because it is awesome). At one
point, it was supported by Walmart Labs. It isn't anymore - it's mostly
supported by the original author (Eran Hammer), who is getting paid less than
$5k per month to develop / support it via patreon (and take a look at the
bimodal distribution on his patreon page). And that's just for part of the
overall ecosystem.

Part of the excitement of js dev is that there's always really useful
libraries being created and distributed (ramda, rxjs, react to just name three
things that start with R).

Not sure there is a good solution here - we want tons of value, but I suspect
nobody's willing to actually pay for it. Libraries like cross-env, ramda, and
so on all are _excellent_ , useful, well-written, and the authors are
responsive.

~~~
thehardsphere
Other programming ecosystems have solved these problems without these glaring
problems, so I don't understand why you're acting as though this is unsolvable
while requiring lots of money.

~~~
notjack
Other programming ecosystems are at least an order of magnitude smaller and
not intrinsically tied to technology that's in relatively extreme flux with a
massive amount of users (browsers).

~~~
nl
_least an order of magnitude smaller_

No they aren't.

It's true that NPM is the biggest package repository by some way, but it's
only ~2x the count of the Maven repository (492135 vs 194954). PHP and Ruby
also have the same order of magnitude.

 _tied to technology that 's in relatively extreme flux with a massive amount
of users_

Maven/Java has similar challenges to some extent with both Android and server
side development being extremely common in the same language. The large number
of users and the extreme technology flux is also similar.

------
phpnode
NPM themselves recently launched a new package called npx [0] which will
_download and execute_ packages directly from the registry if you don't
already have them installed. So if you make a simple typo like this:

    
    
        npx crossenv foo
    

instead of

    
    
        npx cross-env foo
    

you'd have got the malicious version.

[0] [https://www.npmjs.com/package/npx](https://www.npmjs.com/package/npx)

~~~
weetbix
crossenv was already running the script on post install, which means it was
run on "npm i crossenv" anyway.

~~~
phpnode
point is that npm are encouraging you to use npx, which is bundled with npm
5.2+ as a general tool for executing adhoc commands from the terminal. It just
massively increases the chance of typos.

~~~
Spivak
At some point there needs to be some trust, and NPM puts that boundary at
installation. If you trust a package enough to install it, then it's allowed
to act on your behalf with the permissions of your user.

`npx` doesn't change that dynamic. It's no different than installing an RPM or
Debian package over the internet.

~~~
nulagrithom
Imagine if Debian decided that `sduo rm *` meant it should apt-get install the
sduo package and run immediately it.

I know my systrems system wouldn't last 5 minutes.

------
eropple
This is important. It looks like the organization is submerging; they've
deleted their NPM account and the package and emptied their GitHub repo.

This should be signal boosted as hard as it can be managed, because this is
rough stuff.

~~~
codefined
What can be done to help sort problems like this?

~~~
tedunangst
Gardens. With gardeners. And walls.

~~~
i_am_nomad
And money for all three.

~~~
tedunangst
npm has about $10 million, so that shouldn't be a problem.

------
dankent
I've knocked together a quick tool that might help to spot such typosquatting:

[https://www.npmjs.com/package/check-
typosquatters](https://www.npmjs.com/package/check-typosquatters)

(It's the first time I've published anything to npm so let me know if I have
done anything wrong...)

It uses the list of package names from the all-the-package-names package and
returns the 10 packages with the most similar names to the supplied parameter
(using Levenshtein distance)

It also displays their rank based on dependent packages to give an idea of how
they compare in usage.

I'm sure there are improvements that could be made - PRs welcome on the github
repository.

------
lathiat
Just yesterday there was a thread about how the chrome plugin "user agent
switcher" sends your entire browsing history externally. And it's still
published.

The problem is not unique to the npm ecosystem, the main problem here is "web
of trust" whether through GPG or even just things like 'download counts', etc.

~~~
tim333
Also there are at least three chrome extensions in the store called "user
agent switcher" which confuses matters. From useragentswitcher.org, google.com
and toolshack.com

------
fiatjaf
This is issue is not so hard to deal with.

1\. For every big, important package, you can probably count on number of
downloads/stars a library has to attest its trustworthiness.

2\. For small packages, you should always look at the code directly. Search
npm, see the GitHub repository link, click, read the source to see if it more-
or-less does what you want. I think a lot of people do this already.

3\. Typosquatting is still the only unsolved problem, but an addition to the
npm CLI that checks if there are packages with similar names when you're
downloading and alerts you -- maybe even suggesting the package that has much
more downloads/stars -- should solve that.

~~~
Klathmon
Or package authors should start using scoped packages.

Instead of publishing as cross-env you publish as @guy/cross-env

That makes typosquatting harder, and can help give users some ideas of
packages which are by the same authors.

NPM could help by allowing packages to be published both to the "global
namespace" AND as a scoped package automatically. (In other words, always
allow accessing any global package by it's scoped name)

~~~
fiatjaf
Yes, I like that idea.

I would rather have some GitHub integration in place, so I could `npm install
github.com/someone/somepackage`, like Golang forces us to do, for example.

I don't do that for all packages automatically nowadays because there is this
bizarre culture of people publishing different things to npm and GitHub. To
npm they send only "built" files from ES7 to ES5-compatible mode, while to
GitHub go only the unbuilt sources which will not run anywhere.

A solution to that would be for an automatic builder to be run on every `git
push`. A third-party service, somehow, someone, somewhere. Travis CI, maybe?
I'm waiting for someone to have an insight and solve this problem in these
lines.

~~~
johncomposed
Npm has had github integration for a while now (and straight git integration).
Depending on how they setup things, a repo with a good postinstall script will
build once it gets pulled so you'll have ES5 compatible files in your
node_modules by the time you are running your application.

Not that that's an ideal system, but it's an option for some packages.

------
diimdeep
[http://dev.hacktask.org](http://dev.hacktask.org) is look like SAAS for XSS
attacks (free registration, use google translate)

screenshots: [https://imgur.com/a/BGyME](https://imgur.com/a/BGyME)

I found it at
[https://github.com/leanone/v1/blob/2980984c003d8016ac48d3f87...](https://github.com/leanone/v1/blob/2980984c003d8016ac48d3f87ab7f148781fe5f5/application/controllers/test.php#L16)
redirects to
[https://dev.hacktask.org/p/58ad07f57e25ce001b19f776/](https://dev.hacktask.org/p/58ad07f57e25ce001b19f776/)

I created account (use google translate) and played with it, use this link to
show me who you are
[https://dev.hacktask.org/client/59815d7f5ff1a2001b9ee398/](https://dev.hacktask.org/client/59815d7f5ff1a2001b9ee398/)

------
fpgaminer
Is there an api to query recent NPM packages, as well as get a full list of
packages?

It'd be interesting to write a tool that monitors as packages are added to
npm, compare them against the existing list, and check for potential typo-
squatting. Like, remove dashes, check Levenshtein distance, etc.

I mean, NPM themselves should be doing that but ... since they aren't, might
as well do it for them, ya?

~~~
water42
[https://skimdb.npmjs.com/registry/_design/scratch/_view/byFi...](https://skimdb.npmjs.com/registry/_design/scratch/_view/byField)

looks like there is an api

------
kevinsimper
This is serious stuff and we will definitely see more of it in the future! As
there are more and more node.js developers, it will be more profitable to run
a scam like this and you only need to hijack one page that has a lot of
dependencies, one package that is for example used by `express` to get access
to a lot of users.

The only thing you can do is be careful and listen for projects like node
security.

~~~
romanovcode
Or use some other technology.

~~~
eropple
There are remarkably few dependency management systems not vulnerable to some
variant of this attack.

~~~
DCoder
Then again, a project with <20 dependencies has fewer "entry points" for this
attack than a typical NPM project with 500+ transitive dependencies.

------
lsiebert
for every node package, see what node packages are 3 or less levenshtein
distance away when it's uploaded, and go through all existing packages. Add an
optional flag that will, if you try to install a package that has a package
within that edit distance that is an order of magnitude more popular, give you
warning and skip that package, an optional flag that errors, and a way to
force it for a specific package. In the future, make the first optional flag
the default, so people get warnings with instructions to override. Allow white
listing of particular packages that may be problematic, and expect a shared
white list Then, a year later after repeated warnings of the coming
nodepocalypse, make the second optional flag the default, so if you haven't
white listed or explicitly forced installing such a package, it will fail.

You will, of course break production for a few people who just didn't listen.

Alternatively, instead of edit distance, allow users to report problematic
packages and do a similar thing. Do not provide a explicit award to users who
report, so nobody would create fake malware just to report it.

In both cases, either implicitly or explicitly you are using the wisdom of the
crowd to figure out the bad packages.

~~~
krapp
Is there likely to be a good reason for one package name to be two or three
character transforms away from another?

Maybe have all packages be scoped under a namespace, and then globally require
a minimal uniqueness for the package name itself.

------
emeraldd
For reference:
[https://twitter.com/o_cee/status/892306836199800836](https://twitter.com/o_cee/status/892306836199800836)

since the user appears to have been nuked...

~~~
shawnee_
Better link: [https://pbs.twimg.com/media/DGK-
eZ3WsAAvqN0.jpg:large](https://pbs.twimg.com/media/DGK-eZ3WsAAvqN0.jpg:large)

------
ben174
Looks like all the packages by this guy post to hacktask.net - a Chinese site.

Google autocomplete also suggests xss.hacktask.net

Looks like this guy is up to all kinds of no good.

~~~
packetized
...hosted by Cloudflare.

~~~
mrkrabo
Don't understand the downvotes. Cloudflare doesn't seem to have a problem
hosting stuff like this, or even carders, and then ignoring abuse emails :')

------
albertgoeswoof
I wonder why they didn't obfuscate the code a bit more, they could have even
positioned it as a reference package that helps resolve typos.

Would be interesting to know how many systems have potentially been hit by
this, and if any leaked production credentials. I think it's unlikely to yield
a lot of useful results due to then drag net nature of the project. A targeted
attack might make more sense (e.g. On an open source library, targeting
specific developers)

------
RX14
In Crystal, we've decided that the dependency manager shards will have no
centralised package repository, which we hope will solve problems like this.
It makes forking shards very easy, it completely avoids name squatting, and it
should help prevent typo squatting like this.

We also don't want shards to become yet another system package manager, used
for installing executables to your PATH. Shards should never be run as root,
unlike npm and pip.

------
smaili
Looks like it's being logged to _npm.hacktask.net /log_

Couldn't the developer have at least chosen a less suspicious domain name? :)

~~~
JCharante
To be fair hacktask was their username, so they're being consistent.

------
hitgeek
this is really bad for npm.

I think they hold some responsibility in allowing an obviously malicious
package to impersonate popular packages.

I would like to see an official response with action plan. I recall this
attack vector being discussed in the aftermath of left-pad.

an unfortunate irony is that the current post on the npm blog is "Securing the
npm registry" from 12hrs ago.

~~~
Spivak
Not really much they can do other than take it down and maybe 'protect' some
popular packages from typo squatting by reserving some common misspellings.
They're a public repository where users upload arbitrary code. The trust
relationship really isn't there.

You trust NPM to be secure and serve exactly the code that the author
published unmodified.

You trust the author to not act maliciously. Nothing you can really do if a
user voluntaitally installs leet-virus.

------
mjs
Google cache suggests no downloads, fortunately:

[https://webcache.googleusercontent.com/search?q=cache:zAzfBZ...](https://webcache.googleusercontent.com/search?q=cache:zAzfBZIg0vYJ:https://www.npmjs.com/package/crossenv+&cd=1&hl=en&ct=clnk&gl=uk)

~~~
iamakulov
It’s of 19th July :–(

------
reaktivo
Another possible solution for this problem would be that for each module's
`package.json` a list of node APIs that a module opts-out, like http, access
to env variables, fs, etc. This would need to apply to the package itself and
any dependencies it requires.

~~~
krallja
This package was running a Bash script at install time. Perhaps that's the
permission which should be denied.

------
kentor
if you have yarn run

    
    
        yarn why crossenv
    

to see if you have it in your dependency tree

------
Veedrac
All of this seems fixable by just providing decent UI protections. Error when
typo-squat domains near-alias more popular packages; force them to pass a flag
to override.

Is there a reason this isn't done, or has it just not been allocated the time
to build it?

------
unkown-unknowns
I wonder how it was detected. Also someone ITT said something about if they'd
squatted the dependencies it wouldn't have been seen or something? Can't find
back to that comment.

------
hatsunearu
I'm new to the JS ecosystem--who is Oscar and who is Kent?

Also who's hacktask?

~~~
micaksica
Oscar is a dev, Kent is the maintainer of "cross-env", a popular package.
hacktask is an unknown malicious module uploader that was harvesting
credentials.

------
dboy1612
Does anyone know if "hacktask.net" was used in all the rogue packages? Got a
grep running through caches/projects.

------
partycoder
npx makes it even easier. Make a typo while running a command and you are
done.

------
pneiman
Thanks for the heads up

------
danjoc
Friendly reminder, every time this happens...

[https://github.com/npm/npm/pull/4016](https://github.com/npm/npm/pull/4016)

"However, this is just a piece of an overall solution, and it brings with it a
lot of the baggage that comes along whenever GnuPG or PGP get involved.
Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie
identities to trust metrics, this is essentially a complicated, very
expensive, and fragile version of the shasum check npm already has."

I really like how the NPM simultaneously insults two legends in crypto and
does _nothing_ to protect the node ecosystem, deferring to "better solutions"
that don't exist and will never exist.

They've done literally nothing.

[https://github.com/node-
forward/discussions/issues/29](https://github.com/node-
forward/discussions/issues/29)

Last discussion was > 1 year ago. They simply do not care. Security isn't even
an afterthought.

~~~
KirinDave
> I really like how the NPM simultaneously insults two legends in crypto and
> does _nothing_ to protect the node ecosystem, deferring to "better
> solutions" that don't exist and will never exist.

But they're right. What exactly would PKI do here? Someone is generating
confusion.

You could argue that maybe a PKI solution could be used to _inform the UI_
such that users are less likely to make mistakes, but browbeating NPM over
this is silly. Maven has this problem (people really concerned built their own
tools: [https://github.com/whispersystems/gradle-
witness](https://github.com/whispersystems/gradle-witness)), choclatey has
this problem, pip has this problem, _everyone has this problem_.

The big difference is that the NPM ecosystem is just an order of magnitude
bigger than most others, and its model of many small packages can hide many
more key packages in the noise.

~~~
slackingoff2017
Maven does not have this problem. That package was just something you googled
that hasn't been updated in two years because maven has required signed
packages forever. My packages are all cryptographically signed with my private
key. Maven doesn't just offer code signing, it's mandatory to deploy projects
to the central repo. The automated package verifier will reject you if you
don't have it.

If someone gains access to my account and tries to modify my package without
my private key it will not be accepted into the repo.

And actually, I'm pretty sure maven signs not just the code but also the
documentation and everything else within your package.

Light-years ahead of NPM, even after their publicized issues.

~~~
detaro
How does "You need my private key to sign the cross-env package" stop someone
from creating a "crossenv" package? What does the specific workflow look like
that makes sure I don't add the wrong thing to my project?

~~~
danjoc
I can explain how it can be done. Let's say you need a new dependency. You
can't just add it to the project. Management would kill you. There's a lot of
checks you have to make. Like licenses and signatures.

In this case, you're concerned about signatures. I'll stick to that. If I
believe I need crossenv, I see it advertises kent@doddsfamily.com as the
author. I look up Kent Dodds. I find various bits of information about him. I
find his twitter @kentcdodds for instance. He may even have a page published
@doddsfamily.com to verify his key.

If the key has been around for a while, that's probably sufficient for me. If
he doesn't have such a page, I send him a polite message, "Hi Kent. I'm
evaluating your software for use in my project. Can I get you to verify your
key please?" and Kent is a professional, so he agrees. I send
kent@doddsfamily.com an encrypted message and he sends me an encrypted reply.
Done. I'm satisfied that he controls the key.

At this point... oh, wow. That's not my key! Did you say crossenv? My package
is cross-env! Alert the Node authorities! There's a malicious package
pretending to be mine!

Is that 100% infallible? No, but here's the great thing. Even though my
verification system may not be bulletproof, others with resources like DoD or
FBI are out there verifying keys. They'll go see Mr Dodds, in person, if they
have to. In this way, key verification is a bit like herd immunity. And the
older the key is, the more trustworthy it probably is.

People who are here arguing against this system have a few things in common.
They don't propose a better system, because they don't have one. They're also
a bit like anti-vaxers. They irrationally refuse to participate in such a
system to everyone elses' detriment. They're a bit like congress as well. They
can't just look at a working system like single payer, and copy it. They
refuse to accept that this is the best available option, so they fold their
arms and actively fight any attempt to implement it, as is the case on that
github 4016 issue.

So now that I've maybe offended everyone, strike me down with down votes.
That's the basics of how I would go about it though.

~~~
KirinDave
Hashes already exist. The problem is not a lack of integrity verification. We
have that. The problem is not a lack of identity verification, we haven't
really shown that NPM is lacking for that.

The problem is one of addressing. People want to get packages by a utf8 and
natural language string, followed by a version boundary check.

If people referred to packages by their proper hash (as one does when
referencing values from IPFS), then we wouldn't have this problem. If people
had a public key and added a key fingerprint that would also work, but would
not provide any additional verification to the code (1).

But people don't want to do this. They want to address packages by relatively
simple and memorable tuples. That is the problem.

> They're also a bit like anti-vaxers. They irrationally refuse to participate
> in such a system to everyone elses' detriment. They're a bit like congress
> as well. They can't just look at a working system like single payer, and
> copy it.

You aren't even in Keybase. Have you personally participated in any keysigning
parties? Can I find your public key details here?

I can answer yes to all 3 above questions.

> So now that I've maybe offended everyone, strike me down with down votes.
> That's the basics of how I would go about it though.

You haven't actually offended everyone. What you haven't done is say anything
that anyone else doesn't know already. We all know how signature verification
worksheet and we all have seen it's problems in real world implementations.

Please reconsider paragraphs like this.

(1) :: The thing this would do is make it arguably more secure contacting the
author or maintainers of the code, although given GPG's failure to achive
widespread adoption or integration in popular tooling, it seems unlikely it'll
see much utility.

~~~
slackingoff2017
Maven prevents this as well. To add a package to the global repository you
need to show ownership of your namespace by posting your key, your website,
your email, or most commonly these days your GitHub repo with identifying
information. They do check to make sure you're allowed to use each package
identifier.

All package submissions are hand-curated, which should catch typosquatters.
There's a clearly laid out pattern for what package space you're allowed to
use based on website or company ownership.

The system is highly automated but you have to wait to get your namespace
approved. And it's not unrealistic to do this with npm, maven has somewhere
over a million packages.

~~~
jondubois
Well npm requires you to login through their CLI in order to publish
packages... The only difference is that you use a password instead of a key.
No difference.

~~~
camus2
> Well npm requires you to login through their CLI in order to publish
> packages... The only difference is that you use a password instead of a key.
> No difference.

Yes, there is a difference, released must be digitally signed on maven. They
are not on NPM, so a hacker can hijack your packages just by obtaining your
npm credentials.

That's crypto 101 and you can't tell the difference?

~~~
KirinDave
> so a hacker can hijack your packages just by obtaining your npm credentials.

Couldn't they 'just' steal your GPG key as well? If someone can trivially
steal a strong password from you, I'd worry about key material as well.

> That's crypto 101 and you can't tell the difference?

Please reconsider sentences like these.

~~~
sloppycee
The issue is of who to trust, the package maintainer or the package
repository?

It is comparatively trivial to steal a strong password when it is transmitted
over the internet vs local key material.

Nation states with bad certs (china has done this) can steal your password,
npm can steal your password, npm can be hacked and leak passwords, npm can be
subject to a NSL and forced to hand over passwords, etc, etc.

There is a _big_ difference between passwords and keys.

~~~
KirinDave
> The issue is of who to trust, the package maintainer or the package
> repository?

Interesting framing.

> It is comparatively trivial to steal a strong password when it is
> transmitted over the internet vs local key material.

"Comparatively trivial?" I don't really understand this. I think you're
suggesting that SSL cert attacks are easier than evil maid attacks due to this
paragraph:

> Nation states with bad certs (china has done this) can steal your password,
> npm can steal your password, npm can be hacked and leak passwords, npm can
> be subject to a NSL and forced to hand over passwords, etc, etc.

Pardon me, but we're so far afield of the actual reality and the logistics
that plague it that I decline to continue this conversation. If your adversary
is nation states, you need a code audit (preferably several). You can't trust
the signatures precisely because nation states are so well equipped to perform
evil maid attacks.

It is 2017, evil maid attacks are the reality of the nation-state intelligence
industry. We're seeing examples of them leaking out. They're in active use not
just in a targetted mechanism, but _speculatively_! We have evidence
intelligence agencies sell comprimised USB keys in bulk near the physical
locations targets are likely to enter _just to see if they can catch them in a
moment of bad opsec_.

Honestly this all feels like an attempt to say, "We should use GPG because it
is good." Maybe it is. I'm not so sure, given the logistical reality.

But it _wouldn 't prevent the attack we see in the tweet above_. It _wouldn 't
make the root post of this thread correct._ And I'm not sure it would
accomplish what you're saying.

I'm sorry, I simply don't have time to chase this degree of abstracted
hypothetical on a day old thread. I'm writing this final message here as a
courtesy to those involved.

~~~
sloppycee
Just consider: \- China issues a bad cert for npm \- Slurps up all passwords
from Chinese maintainers en masse

Now we can't trust any package published from China.

This is a bigger deal than a targeted evil maid. Distributed trust is better
than centralized trust.

~~~
KirinDave
Distributed trust isn't better than centralized trust. In fact, it'll fail
more often. It's just that the failures have varying degrees of severity.

Same principle as saying, "I will make my website more reliable by adding more
servers." In fact you make it less reliable by doing so, you just change the
severity of the problems.

And we've seen economic mechanisms compromise signed star-shaped trust graphs.
E.g., all these atom plugins with features/spyware circulating because a small
handful of companies think it's a business model. That's literally just buying
the property from folks and ruining it. That's a very powerful attack against
a web of trust and often cheaper than the fake cert attack, which is actually
something you can guard against if you feel inclined to do so.

------
xxxdarrenxxx
This is not unexpected if u take into account behind all the code are still
_humans_.

Everyone can share everything for free, safe and sound in a happy world.

Didn't happen ever in the "real world", won't happen here. It's idealistic
bias.

I'm sure many things have been written on this, but this is essentially an
issue rooted in human behaviour.

It always comes down to having a or multiple arbiter(s) to maintain a
standard. The issue with this in these type off ecosystems is that it's simply
too big and too dynamic unless devs and the curators are on common terms
release wise.

By now you basically are threading being an organisation potentially elevating
privileges with just a small portion off devs to realistically deal with the
scale off things. In this centralized state it can swing the other way,
mainting heavy arbiting and release standards (Apple for example), creating a
potential more stable and secure but closed system.

------
infinity0
nodejs lack-of-QA comes back to bite them in the ass yet again. wasn't the
first time nor will it be the last time, ditch this bullshit.

~~~
eropple
Explain to me how "QA" prevents a malicious package from transitively
including another one and taking advantage of typo squatting.

~~~
tedunangst
QA prevents someone from adding a typo to the repository.

~~~
eropple
Your QA teams are looking up every entry in your package.json files, your
Maven poms, your Gemfiles, your requirements.txt files? They're making sure
that something that builds completely cleanly and shows no external errors
doesn't have a typo in it?

Of course they're not.

~~~
tedunangst
My QA team, upon a request to add a package called "crossenv" to the npm repo,
would say "this is suspiciously similar to the existing cross-env package.
Request denied." Alas, npm has no such team.

~~~
Chyzwar
npm host half a million packages. It is impossible to manually QA anything.
People also rename and re-publish unmaintained packages pretty often.

The problem is JS that lack sensible standard library. Node is at fault.

~~~
tedunangst
A problem that exists because there was no QA to start... Instead we get
"awesome" lists of "curated" packages on github, which does nothing to solve
the problem.

