7 ms·

In short: Someone has published a version 3.7.2 of eslint-scope that contains unwanted code. The code tries to read your credentials and send them to some track

In short: Someone has published a version 3.7.2 of eslint-scope that contains unwanted code. The code tries to read your credentials and send them to some tracking pages. Webpack and more uses ^3.7.1 of the dependency, making you automatically upgrade to the hacked one. Update: According to the linked issue the nefarious package has now been unpublished. If you have npm credentials and did npm install the last few hours you should probably revoke your tokens.

windows_tips 8y ago
npm is distributing this credential tracker?
deleted 8y ago
[deleted]
zalebz 8y ago
source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github releases? can the eslint-scope team not figure out the someone that did the publish? I'm an open source newb but I have to think someone had to accept this malicious code at some point for it to ripple through and make it to release/publish right?
- fmpwizard 8y ago
  npm doens't take the code directly from the github repo, so far it looks like the new code was publish directly to npm, so there is no git commit to look at as it never was part of the official github repository
- mklauber 8y ago
  From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.
  - consumer451 8y ago
    > someone published their own code instead of code from the github repo Sorry for my ignorance, I have not been a real dev for over 10 years, but wouldn't a better way for NPM to take new packages be for NPM to own the build process? As in the owner of a package would tell NPM: please build and publish from this previously registered repo. Then NPM would have it's own Jenkins servers actually run the build? Based on my very limited understanding the main problem I see with NPM is that I have no idea if the code in the repo was the same code used to build the package. This is what happened in this case, correct? Wouldn't NPM owning the build process solve this problem? I realize this would be a huge load for NPM, but NPM has the world's security riding on its shoulders. I'm ready to be told why this is dumb now... edit: grammar
    - mijamo 8y ago
      But how would you know that the sourced on NPM same as the ones you have? Except if you require all NPM packages to be hosted on Github but that does not seem like a good idea to me.
      - consumer451 8y ago
        Couldn't some simple standard be developed to allow non-github repo hosts to also be used?
        proneb1rd 8y ago
        Like gpg the payload and make sure npm has a public key.
    - PeCaN 8y ago
      No, that's a fine idea and would've prevented this problem. The build reflecting the repo is a very sane thing to do. Unfortunately NPM is run and used by morons so that'll not happen.
      - 8y ago
- shusson 8y ago
  publishing is separate to the source code. If someone stole the publishers credentials, then they could publish [1]. Only NPM servers would be able to know something special (not the credentials) about who did the publish, e.g IP. [1] https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag...
- dpkonofa 8y ago
  The someone was a publisher for ESLint whose credentials were stolen separately from this. The malicious code itself isn't stored in the codebase, it's stored in a pastebin doc that's called by URL. Theoretically, the person that did this can change the content of that pastebin file at any time to get new/different code run on machines that have this installed.
Vinnl 8y ago
> If you have npm credentials and did npm install the last few hours you should probably revoke your tokens. You might have to do that anyway - it's not yet clear what other packages, if any, have been affected.

windows_tips 8y ago

npm is distributing this credential tracker?

deleted 8y ago

[deleted]

zalebz 8y ago

source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github releases? can the eslint-scope team not figure out the someone that did the publish? I'm an open source newb but I have to think someone had to accept this malicious code at some point for it to ripple through and make it to release/publish right?

fmpwizard 8y ago
npm doens't take the code directly from the github repo, so far it looks like the new code was publish directly to npm, so there is no git commit to look at as it never was part of the official github repository
mklauber 8y ago
From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.
- consumer451 8y ago
  > someone published their own code instead of code from the github repo Sorry for my ignorance, I have not been a real dev for over 10 years, but wouldn't a better way for NPM to take new packages be for NPM to own the build process? As in the owner of a package would tell NPM: please build and publish from this previously registered repo. Then NPM would have it's own Jenkins servers actually run the build? Based on my very limited understanding the main problem I see with NPM is that I have no idea if the code in the repo was the same code used to build the package. This is what happened in this case, correct? Wouldn't NPM owning the build process solve this problem? I realize this would be a huge load for NPM, but NPM has the world's security riding on its shoulders. I'm ready to be told why this is dumb now... edit: grammar
  - mijamo 8y ago
    But how would you know that the sourced on NPM same as the ones you have? Except if you require all NPM packages to be hosted on Github but that does not seem like a good idea to me.
    - consumer451 8y ago
      Couldn't some simple standard be developed to allow non-github repo hosts to also be used?
      - proneb1rd 8y ago
        Like gpg the payload and make sure npm has a public key.
  - PeCaN 8y ago
    No, that's a fine idea and would've prevented this problem. The build reflecting the repo is a very sane thing to do. Unfortunately NPM is run and used by morons so that'll not happen.
    - 8y ago
shusson 8y ago
publishing is separate to the source code. If someone stole the publishers credentials, then they could publish [1]. Only NPM servers would be able to know something special (not the credentials) about who did the publish, e.g IP. [1] https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag...
dpkonofa 8y ago
The someone was a publisher for ESLint whose credentials were stolen separately from this. The malicious code itself isn't stored in the codebase, it's stored in a pastebin doc that's called by URL. Theoretically, the person that did this can change the content of that pastebin file at any time to get new/different code run on machines that have this installed.

Vinnl 8y ago

> If you have npm credentials and did npm install the last few hours you should probably revoke your tokens. You might have to do that anyway - it's not yet clear what other packages, if any, have been affected.