A former GitHub employee recently raised concerns about a weakness in Node Package Manager (npm) that could potentially allow individuals to hide malicious dependencies and scripts within their packages. Npm, which is owned by GitHub, is a widely used platform for sharing JavaScript code and serves over 17 million developers worldwide. It is considered the largest software registry globally, hosting more than 2 million packages.
In a blog post titled “manifest confusion,” Darcy Clarke, a former staff engineering manager for npm’s command line interface team, shed light on the issue. The confusion arises from npm’s failure to validate the metadata associated with each package. This loophole enables publishers to conceal important information about their packages, including the scripts it contains and the dependencies it relies on.
The discovery of this weakness comes at a time when npm and similar repositories have faced increasing pressure due to the rise in hacker attacks targeting code supply chains. Hackers have been devising innovative methods to insert malicious code into packages and distribute malware. However, npm’s security risks are not solely caused by malicious actors. Some vulnerabilities stem from the platform’s own shortcomings, such as its inadequate measures against typosquatting.
The problem lies in the fact that npm does not automatically cross-reference a package’s “manifest” – the information visible to users when they visit a package’s page – with its package.json file, which outlines the package’s contents. Both the manifest and package.json contain crucial metadata, including information about scripts and dependencies. Ideally, these two sources should align, but a publisher can manipulate a package’s manifest without detection from npm. To demonstrate this issue, Clarke created an npm package with a manifest that deliberately omits any evidence of dependencies mentioned in its package.json file.
This manipulation of package metadata enables publishers, and potentially hackers, to conceal the presence of malware from unsuspecting developers. The discovery of this weakness raises questions about npm’s lack of validation mechanisms to ensure consistency between a package’s manifest and its package.json file.
Clarke suggests that the historical development of the node ecosystem might partly explain npm’s approach. During the nascent stages of the ecosystem, trust among contributors was higher due to the smaller community size, and most aspects of the npm registry were open source and subject to inspection. Consequently, npm might not have recognized the need for server-side validation.
As of now, GitHub, the owner of npm, has not issued a public response to these concerns. Clarke reported the manifest confusion weakness to GitHub on March 9, but the ticket was closed with the company stating that they were handling the issue internally. Despite GitHub’s awareness of the problem since at least November 4, 2020, there have been no significant updates.
The lack of progress in addressing the manifest confusion weakness poses a challenge for GitHub. Since npm’s functioning has been largely consistent for over a decade, rectifying the issue might require substantial changes. However, developers can mitigate the risk by relying solely on metadata provided by a package’s contents rather than its manifest.
Additionally, industry experts emphasize the importance of practicing caution when dealing with third-party code. Developers and organizations should thoroughly vet the sources of any libraries they use, especially those that are obscure, older, or have seen limited development. Various companies offer automated tools that can scan code for potential exploits and unusual features, which should be integrated into developers’ toolkits. Validating packages should become a mandatory step in any project that depends on third-party libraries.
In conclusion, the manifest confusion weakness in npm raises concerns about the platform’s security and the potential for hiding malware within packages. GitHub, the owner of npm, needs to address this vulnerability promptly to safeguard the integrity of the code supply chain. Developers must also play their part by exercising caution and utilizing tools that can help identify and mitigate potential risks posed by third-party code.