ESLint-scope 3.7.2 has been hacked #21202
Comments
3.7.2 seems to have been unpublished now. Would love to hear what actually happened. |
@akx shortly, the npm credentials have been stolen and the malicious release has been made directly to npm (not GitHub). The malicious code ran upon Surprisingly, the tampered code only contained a bootstrap script that downloaded and executed the main script (with All of what happened is something to think about, why didn't npm spot the calls to |
The first question that came to mind after seeing this issue is: why is there a difference between the published code on npm, and the code on github? I know why, because when you run I think npm can increase security by not letting people publish code from their local directories but only download code from a public repo like github’s (ala server-to-server). It would of course only be possible for public modules/repositories. That way all published code always has a history. It increases security because to publish malicious code you need to:
I'm probably not the first with this idea, but has it been considered by the npm team yet? I can also imagine that the world would be a safer place if |
@branneman that's true, but some code is transpiled upon release so this has an impact of forcing developers to store all their stuff in git or put the strain on npm servers to pull the code and run all build procedures before publishing. Anyway, there must be a way. 👍 |
fyi @pronebird all files showing Oct 26, 1985 (a Back to the Future reference joke) is actually intented behavior for NPM (see #20439 (comment)) and not related to this hack. |
The actual solution would be https://reproducible-builds.org/ Fixating on one build environment is not a good idea in the grand scheme of things. |
@jpdriver Thanks, I didn't know this. I mostly use |
Has already the attacker got tokens by this attack? If so, will other packages be hacked again? |
It seems like the reasonable thing to do would be:
|
The key is revoking all npmrc tokens globally before the attacker takes action. If this isn't done soon enough, the only way to completely prevent the damage will be the manual audit of the almost the npm registry, and that is borderline impossible. (so I'm really hoping npm revokes everything soon enough, otherwise most people will just have to stop using it) |
@EdwardDrapkin Agree with all of your points, but I'd go a step further with number 2: in addition to searching the registry, unpublish all packages published since the affected version was published (and even then, it's not clear yet if the eslint-scope infection was a result of a further upstream infection). The virus could have modified itself (or have been manually modified, or use a different version entirely) so as to be unrecognizable from the original. There's nothing to say that the pastebin code from this incident is the same as what would be infected in other packages of authors with their credentials compromised. The credentials are being logged to web counters, which to use the credentials they would have to be monitored from an outside source, so there's nothing stopping that outside source from publishing a different script entirely. Edit: upon further thought, I realize that my suggestion should only be done if it is determined that a significant amount of packages are affected after halting all package publications and revoking all tokens. It's possible that could effectively resolve this specific incident. However this should at least be a "shot across the bow" that a single token being compromised can have disastrous ripple effects across the ecosystem. |
Everyone, I am not sure where else to put this and the eslint-scope issue has been locked, but is there anyway to search the npm cache to make sure this version is not cached? I am on windows if it helps or doesn't. |
The script seems to have run successfully on one user's Windows system. The "problem" in the script seems to have been that it would only run correctly if the full source code was fetched in the first chunk - the malware author forgot to ensure all chunks had been fetched. I gleaned this from the original eslint-scope issue. So it is reasonable to expect many users' auth tokens to have been stolen. |
I +1 the global unpublishing of all packages and revoking all tokens until this is resolved. This does NOT look good. |
@branneman and others suggesting npm integration into git, Not every npm package uses git, and certainly not everyone uses github. Marrying the two concepts doesn't make sense to me. I think the best solution is faster communication and awareness of exploited packages. Some brainstorming ideas:
|
Just forbid all packages containing a string "eval", or make them require manual reviewal. But my advise would be just ban them for good |
@gedgaudasnikita how would that help? then they write the code to a file, and btw, why do you have two accounts? @nikita-gedgaudas-ht / @gedgaudasnikita - AFAIK the GitHub ToS only allow one account per human |
@gedgaudasnikita yea but what about using Function constructor syntax::
I feel like you are addressing the symptom by banning eval not the root problem. |
@gedgaudasnikita That won't work. Eval is needed for a lot of things, and banning it won't do. We need package signing - which NPM actively rejected, but I feel like this has a use right now judging from the current events right now |
This does not work well with some JS perf optimization patterns. See the monomorphization that improved webpack's speed by ~80% between version 3 and 4. |
Probably the only acceptable long-term solution is to allow and encourage package signing, with the ability to use a second factor (such as a hardware key) for the signing. Whoever stole the eslint-scope creds could also have stolen signing creds, if they were not using 2 factor auth. It will take a long time for the majority of package maintainers to reach this level of security awareness, but it's a project that must be started. |
@OliverUv +1 on that but I don't know why NPM rejected this - it was a majorly a good security practice |
We've updated our status page about this incident. I'm going to lock this thread because it's likely to draw a lot of traffic and I think actual information will be buried. Please keep an eye on the status page, our social media, npm.comminuty announcements, or this thread for any particularly big things. While you're here, a reminder that this issue tracker is closing in favor of npm.community, so please direct issues and such to that space. This issue tracker will be closing very soon. |
(update: apologies, my original post included a link to this issue instead of the actual status page. The link has been updated) |
Bumps [@types/eslint-scope](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/eslint-scope) from 3.7.1 to 3.7.2. - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/eslint-scope) --- updated-dependencies: - dependency-name: "@types/eslint-scope" dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Please see the following issue:
eslint/eslint-scope#39
eslint-scope
3.7.2 has been published an hour ago which is a hacked version that steals the NPM accounts or something.Please pull the version 3.7.2 from the npm and freeze the account so this does not get propagated.
As a matter of fact, there is no release tag for 3.7.2 on Github, so I think it would be great to consider double checking with Github repository before publishing any code.
This would at least limit the possibility of uploading the malicious code to NPM without having Github credentials to tag the release/version.
Additionally I believe it's possible to check if the release was signed and somehow enforce all tagged commits to be signed. I think Github returns such information via their API, at least you can see the verified commits via Github's web interface so there must be a way. Developer may be able to opt-in for this extra security via some
.rc
file stored in Git repo.The text was updated successfully, but these errors were encountered: