GitHub specialists talked about vulnerabilities in npm

The GitHub specialists talked about two serious vulnerabilities in npm (Node Package Manager), identified in the JavaScript package manager in October-November of this year.

The first and most serious error, which cybersecurity researchers reported to developers via the bug bounty GitHub program in early November, allows an attacker to publish a new version of any npm package using an account without correct authorization.

The vulnerability stemmed from inconsistency in authorization and data checks between several microservices that process requests to npm.

Mike Hanley

In this architecture, the authorization service correctly checked the user’s authorization for packages based on the data passed in the request URL paths. However, the service that performed the basic registry data updates determined which package to publish based on the contents of the uploaded package file. This inconsistency created the possibility where requests to publish new versions of a package were allowed for one package, but were actually executed for another, potentially unauthorized package. We addressed this issue by ensuring consistency between the publishing and authorization services to ensure that the same package is used for both authorization and publishing.explains GitHub head of security Mike Hanley.

The developers write that there is no evidence of exploitation of this bug. But at the same time, experts admit that the vulnerability existed in npm “over a time interval”, for which they have telemetry, “which allows determining whether this vulnerability has ever been abused.”

The second vulnerability was related to a leak of the names of private npm packages (but not their contents), which occurred through the npmjs.com replication server, from which third-party services receive these data. The leak affected private npm libraries that look like “@ owner / package” and were built before October 20th. The names of these libraries were available to outsiders between October 21 and October 29. The leak has now been fixed and the data has been deleted.

While maintaining the database that maintains the public npm replica at replicate.npmjs.com, records were created that could reveal the names of private packages. For a short time, this allowed the consumers of replicate.npmjs.com to learn the names of private packages from posts posted to the public change feed. No other information, including the contents of these private packages, was available.Hanley explains.

The problem is that even a simple knowledge of the names of private packages is quite enough to carry out targeted and automated attacks such as dependency confusion and typosquatting. Experts admit that replicate.npmjs.com is being used by third parties, which means they can still keep copies of the leak or “replicate data elsewhere.”

Let me remind you that we also reported that Another npm package was stealing information from browsers and Discord.

Sending