6 ms·

As a user/developer how do you even mitigate against this kind of attack? Audit all source that you or your dependencies use?

by msl09 8y ago

Sir_Cmpwn 8y ago
The honest answer is a hard truth: you don't use npm at all. The npm ecosystem is out of control and beyond saving. I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is - trusted third-parties that independently audit and publish new packages. Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.
- rufugee 8y ago
  It seems that Node would really benefit from a "NPM is a Ghetto" post similar to Zed's Rails rant.
  - busterarm 8y ago
    And risk getting pilloried by the community for being divisive? Or worse, for triggering someone? Zed has taken a way-out-of-proportion amount of heat (and mostly people just trying to bait him) from people for his confrontational style. Even then, the social climate is much less receptive to that sort of thing now than it was then.
  - Jach 8y ago
    It had that post 7 years ago: https://www.semitwist.com/mirror/node-js-is-cancer.html https://www.semitwist.com/mirror/node-js-is-cancer.html It was about Node specifically, though, not NPM. "Yudkowsky's Law of Continued Failure says that if they're dumb enough to do X, they're dumb enough to go on doing X after the next stimulus." In this latest saga of NPM-related fail, it's just another stimulus, so don't expect anything to happen that might address the underlying problems of the ecosystem.
    - ricardobeat 8y ago
      That's a terrible article (such a blind view on async I/O), and totally unrelated to the security model of package managers.
      - Jach 8y ago
        I did say it was about Node, not NPM, but you're right on the article quality too. I even used Node after reading that post..and liked it. But actually I was wrong to even associate it with Zed's post, since Zed's post is mainly about the community and not about the technology. I inferred the call for a similar post on NPM to be technology related and pattern matched on the wrong dimension of "poorly received ranty criticism" entirely! Oh well.
- austincheney 8y ago
  > I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is I started one but dont have the time to maintain it. If anybody wants to take it just fork it and go: https://github.com/prettydiff/biddle https://github.com/prettydiff/biddle
- rattray 8y ago
  1. You can protect against problems like "a subdependency's patch version automatically bumped to something bad" with a lockfile, either yarn.lock or package-lock.json. Of course, that doesn't help if you chose to update your lockfile in the handful of hours this attack was live. 2. It seems to me that, accordingly, a client-side command to only download packages/versions that have been live for more than n hours/days would decrease the likelihood of downloading malicious code substantially. The community is large and folks tend to find the bad stuff. 3. If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower. 4. We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can. 5. Yarn operates a mirror, and there are several CDN's with everything on npm - unpkg.com, cdn.jsdelivr.net/npm, bundle.run. Perhaps one of them will let you download everything for examination. I wouldn't be surprised if NPM, Inc. would help you audit the rest of the ecosystem if you reached out.
  - Sir_Cmpwn 8y ago
    >If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower. So? The JavaScript community could stand to slow down a bit. >We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can. They might publish, but they certainly don't audit. Anyone can publish a package on npm in tens of seconds and it's immediately live for anyone to install. It's not even signed. This looks nothing like a Linux distro.
    - Vinnl 8y ago
      > So? The JavaScript community could stand to slow down a bit. It's not "a bit", and it's not just the Javascript community, unfortunately. Practically every software project pulls in heaps of unaudited third-party code.
      - Sir_Cmpwn 8y ago
        I disagree. Most projects pull in an order of magnitude fewer dependencies than your average JavaScript project, if not even fewer.
- deleted 8y ago
  [deleted]
- throwanem 8y ago
  Sure you can. The first public mirror list I know offhand is https://github.com/amio/npm-mirrors/blob/master/index.js https://github.com/amio/npm-mirrors/blob/master/index.js. You can also make your own mirror. See https://eatpeppershothot.blogspot.com/2016/12/how-to-create-mirror-of-entire-npm.html https://eatpeppershothot.blogspot.com/2016/12/how-to-create-... for a quick overview. Come to think about it, if you're not a fan of the paucity of public mirrors evinced by the first link, you could use the second one to do something significant toward improving that situation. But I grant it's easier merely to criticize.
  - Sir_Cmpwn 8y ago
    I retract my statement about the lack of mirrors.
Rjevski 8y ago
Ideally yes. This is doable with some languages but the issue with Javascript is that your dependency graph usually ends up containing 100+ packages.
ndonnellan 8y ago
I highly recommend using package-lock.json files and npm ci in a ci-environment. That way your automated processes aren't changing dependencies. And even if you use npm install, your lock files act as a source of history to inspect what changes occurred between new installs.
naasking 8y ago
> As a user/developer how do you even mitigate against this kind of attack? I wish there were a viable answer other than "use a capability-secure programming language". Even auditing is insufficient since nefarious code can easily slip through even an audit.

As a user/developer how do you even mitigate against this kind of attack? Audit all source that you or your dependencies use?

by msl09 8y ago

As a user/developer how do you even mitigate against this kind of attack? Audit all source that you or your dependencies use?

Sir_Cmpwn 8y ago

The honest answer is a hard truth: you don't use npm at all. The npm ecosystem is out of control and beyond saving. I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is - trusted third-parties that independently audit and publish new packages. Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.

rufugee 8y ago
It seems that Node would really benefit from a "NPM is a Ghetto" post similar to Zed's Rails rant.
- busterarm 8y ago
  And risk getting pilloried by the community for being divisive? Or worse, for triggering someone? Zed has taken a way-out-of-proportion amount of heat (and mostly people just trying to bait him) from people for his confrontational style. Even then, the social climate is much less receptive to that sort of thing now than it was then.
- Jach 8y ago
  It had that post 7 years ago: https://www.semitwist.com/mirror/node-js-is-cancer.html https://www.semitwist.com/mirror/node-js-is-cancer.html It was about Node specifically, though, not NPM. "Yudkowsky's Law of Continued Failure says that if they're dumb enough to do X, they're dumb enough to go on doing X after the next stimulus." In this latest saga of NPM-related fail, it's just another stimulus, so don't expect anything to happen that might address the underlying problems of the ecosystem.
  - ricardobeat 8y ago
    That's a terrible article (such a blind view on async I/O), and totally unrelated to the security model of package managers.
    - Jach 8y ago
      I did say it was about Node, not NPM, but you're right on the article quality too. I even used Node after reading that post..and liked it. But actually I was wrong to even associate it with Zed's post, since Zed's post is mainly about the community and not about the technology. I inferred the call for a similar post on NPM to be technology related and pattern matched on the wrong dimension of "poorly received ranty criticism" entirely! Oh well.
austincheney 8y ago
> I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is I started one but dont have the time to maintain it. If anybody wants to take it just fork it and go: https://github.com/prettydiff/biddle https://github.com/prettydiff/biddle
rattray 8y ago
1. You can protect against problems like "a subdependency's patch version automatically bumped to something bad" with a lockfile, either yarn.lock or package-lock.json. Of course, that doesn't help if you chose to update your lockfile in the handful of hours this attack was live. 2. It seems to me that, accordingly, a client-side command to only download packages/versions that have been live for more than n hours/days would decrease the likelihood of downloading malicious code substantially. The community is large and folks tend to find the bad stuff. 3. If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower. 4. We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can. 5. Yarn operates a mirror, and there are several CDN's with everything on npm - unpkg.com, cdn.jsdelivr.net/npm, bundle.run. Perhaps one of them will let you download everything for examination. I wouldn't be surprised if NPM, Inc. would help you audit the rest of the ecosystem if you reached out.
- Sir_Cmpwn 8y ago
  >If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower. So? The JavaScript community could stand to slow down a bit. >We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can. They might publish, but they certainly don't audit. Anyone can publish a package on npm in tens of seconds and it's immediately live for anyone to install. It's not even signed. This looks nothing like a Linux distro.
  - Vinnl 8y ago
    > So? The JavaScript community could stand to slow down a bit. It's not "a bit", and it's not just the Javascript community, unfortunately. Practically every software project pulls in heaps of unaudited third-party code.
    - Sir_Cmpwn 8y ago
      I disagree. Most projects pull in an order of magnitude fewer dependencies than your average JavaScript project, if not even fewer.
deleted 8y ago
[deleted]
throwanem 8y ago
Sure you can. The first public mirror list I know offhand is https://github.com/amio/npm-mirrors/blob/master/index.js https://github.com/amio/npm-mirrors/blob/master/index.js. You can also make your own mirror. See https://eatpeppershothot.blogspot.com/2016/12/how-to-create-mirror-of-entire-npm.html https://eatpeppershothot.blogspot.com/2016/12/how-to-create-... for a quick overview. Come to think about it, if you're not a fan of the paucity of public mirrors evinced by the first link, you could use the second one to do something significant toward improving that situation. But I grant it's easier merely to criticize.
- Sir_Cmpwn 8y ago
  I retract my statement about the lack of mirrors.

Rjevski 8y ago

Ideally yes. This is doable with some languages but the issue with Javascript is that your dependency graph usually ends up containing 100+ packages.

ndonnellan 8y ago

I highly recommend using package-lock.json files and npm ci in a ci-environment. That way your automated processes aren't changing dependencies. And even if you use npm install, your lock files act as a source of history to inspect what changes occurred between new installs.

naasking 8y ago

> As a user/developer how do you even mitigate against this kind of attack? I wish there were a viable answer other than "use a capability-secure programming language". Even auditing is insufficient since nefarious code can easily slip through even an audit.