GitHub fixes authorisation vulnerability in the NPM JavaScript package registry
(2021/11/16)
- Reference: 1637083988
- News link: https://www.theregister.co.uk/2021/11/16/github_npm_flaw/
- Source link:
GitHub said it has fixed a longstanding issue with the NPM (Node Package Manager) JavaScript registry that would allow an attacker to update any package without proper authorisation.
Chief security officer Mike Hanley [1]posted yesterday about the issue, which was reported by security researchers Kajetan Grzybowski and Maciej Piechota on 2 November and patched within six hours. That impressive speed contrasts with the length of time the vulnerability existed, said to be longer than "the timeframe for which we have available telemetry, which goes back to September 2020."
The vulnerability was based on a familiar insecurity pattern, where the system correctly authenticates a user but then allows access beyond what that user's permissions should enable. In this case, the NPM service correctly validated that a user was authorised to update a package, but "the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.
[2]
"This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package."
[3]
[4]
NPM is an essential resource for millions of developers; for example, one of the most popular packages is lodash, a JavaScript utility library that is downloaded around seven million times a day. The consequences of a malicious version of such a package would be severe, which is why Hanley added that "we can say with high confidence that this vulnerability has not been exploited maliciously" at least since September 2020.
Hanley also revealed that the names of some privately published packages, which should not be listed on the public registry, were inadvertently exposed via a public NPM replica, for about a week. The content of the packages were not accessible, though, and this was fixed on 29 October.
[5]NPM packages disguised as Roblox API code caught carrying ransomware
[6]If you're using this hijacked NPM library anywhere in your software stack, read this
[7]JavaScript library downloaded 3m times a week exposes apps to hijacking via evil proxy configs
[8]GitHub's npm gave away a package name while it was in use, causing rethink
GitHub is planning to tighten the security of the NPM registry by requiring two-factor authentication (2FA) for maintainers and admins of the most popular packages, starting in the first quarter of 2022. 2FA is [9]already possible but not required. The 2FA technology used will be [10]WebAuthn . Details of how this will work will be published "in the coming weeks," Hanley said.
The goal is to prevent account takeovers, such as [11]last month's incident involving ua-parser-js. At the time GitHub [12]warned : "Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer."
[13]
The NPM community has also [14]discussed strengthening security via code signing. It is already [15]possible to verify the PGP (Pretty Good Privacy) signature of an NPM package but this only guarantees that the package downloaded matches what was published, and would not help in the case where a package is published but without proper authorisation. ®
Get our [16]Tech Resources
[1] https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2021/10/27/npm_roblox_ransomware/
[6] https://www.theregister.com/2021/10/25/in_brief_security/
[7] https://www.theregister.com/2021/09/03/pac_patch_npm/
[8] https://www.theregister.com/2021/08/10/github_npm_package/
[9] https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification
[10] https://webauthn.io/
[11] https://www.theregister.com/2021/10/25/in_brief_security/
[12] https://github.com/advisories/GHSA-pjwm-rvh2-c87w
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://github.com/node-forward/discussions/issues/29
[15] https://docs.npmjs.com/verifying-the-pgp-signature-for-a-package-from-the-npm-public-registry
[16] https://whitepapers.theregister.com/
Chief security officer Mike Hanley [1]posted yesterday about the issue, which was reported by security researchers Kajetan Grzybowski and Maciej Piechota on 2 November and patched within six hours. That impressive speed contrasts with the length of time the vulnerability existed, said to be longer than "the timeframe for which we have available telemetry, which goes back to September 2020."
The vulnerability was based on a familiar insecurity pattern, where the system correctly authenticates a user but then allows access beyond what that user's permissions should enable. In this case, the NPM service correctly validated that a user was authorised to update a package, but "the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.
[2]
"This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package."
[3]
[4]
NPM is an essential resource for millions of developers; for example, one of the most popular packages is lodash, a JavaScript utility library that is downloaded around seven million times a day. The consequences of a malicious version of such a package would be severe, which is why Hanley added that "we can say with high confidence that this vulnerability has not been exploited maliciously" at least since September 2020.
Hanley also revealed that the names of some privately published packages, which should not be listed on the public registry, were inadvertently exposed via a public NPM replica, for about a week. The content of the packages were not accessible, though, and this was fixed on 29 October.
[5]NPM packages disguised as Roblox API code caught carrying ransomware
[6]If you're using this hijacked NPM library anywhere in your software stack, read this
[7]JavaScript library downloaded 3m times a week exposes apps to hijacking via evil proxy configs
[8]GitHub's npm gave away a package name while it was in use, causing rethink
GitHub is planning to tighten the security of the NPM registry by requiring two-factor authentication (2FA) for maintainers and admins of the most popular packages, starting in the first quarter of 2022. 2FA is [9]already possible but not required. The 2FA technology used will be [10]WebAuthn . Details of how this will work will be published "in the coming weeks," Hanley said.
The goal is to prevent account takeovers, such as [11]last month's incident involving ua-parser-js. At the time GitHub [12]warned : "Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer."
[13]
The NPM community has also [14]discussed strengthening security via code signing. It is already [15]possible to verify the PGP (Pretty Good Privacy) signature of an NPM package but this only guarantees that the package downloaded matches what was published, and would not help in the case where a package is published but without proper authorisation. ®
Get our [16]Tech Resources
[1] https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2021/10/27/npm_roblox_ransomware/
[6] https://www.theregister.com/2021/10/25/in_brief_security/
[7] https://www.theregister.com/2021/09/03/pac_patch_npm/
[8] https://www.theregister.com/2021/08/10/github_npm_package/
[9] https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification
[10] https://webauthn.io/
[11] https://www.theregister.com/2021/10/25/in_brief_security/
[12] https://github.com/advisories/GHSA-pjwm-rvh2-c87w
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZQ4HMTBJoNh9jdeBM0gJQAAARg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://github.com/node-forward/discussions/issues/29
[15] https://docs.npmjs.com/verifying-the-pgp-signature-for-a-package-from-the-npm-public-registry
[16] https://whitepapers.theregister.com/
Anonymous Coward
> It is already possible to verify the PGP (Pretty Good Privacy) signature of an NPM package but this only guarantees that the package downloaded matches what was published, and would not help in the case where a package is published but without proper authorisation.
If the downloaded-from-NPM package hash were matched to a hash stored at the source project location - e.g., github, gitlab, bitbucket, etc. - that *could* be more secure, because it would require two compromises. Provided the source project location and the npm package were truly independent. If the source project location were taken from the npm package.json file then it could obviously be a fake source project location.
And if the are a dozen or hundreds of dependencies, then manual checking of each hash stored at the source project is infeasible.
Supposing that source project repos were more secure than the NPM package repos, the source project could be used as a pointer to the NPM repo, along with the expected hash. That shouldn't be too much of a burden on the gitXXX provider in terms of delivery load. Obviously some problems with that plan too - it's still not independent and only requires one compromise - it's yet another standard - the first dependency that does not use it break the security of all dependencies below it.
Cold comfort ......
Hanley also revealed that the names of some privately published packages, which should not be listed on the public registry, were inadvertently exposed via a public NPM replica, for about a week. The content of the packages were not accessible, though....
Sometimes just the name of a private package can reveal the true enough nature of the contents therein.