Npm Plagued With Manifest Confusion Malware-Hiding Weakness

The popular package manager for software developers has been vulnerable to this attack vector for a while, and negligent in fixing the problem, according to a former employee.

A weakness in Node Package Manager (npm) could allow anybody to hide malicious dependencies and scripts within their packages, a former GitHub employee claims.
Npm is owned by GitHub and is used for JavaScript code sharing, serving more than 17 million developers. Its the worlds largest software registry, containing more than 2 million packages,
according to the website
.
In
blog post on June 27
, Darcy Clarke, former staff engineering manager for npms command line interface team, detailed a weakness in the site he named manifest confusion.
The confusion arises from the fact that npm doesnt validate the metadata associated with any given package, theoretically enabling any publisher to hide certain information about their packages, including the scripts it runs and the dependencies on which it relies.
Npm —
and other repositories like it
— has been
under pressure in recent months
, with more and more hackers devising
novel methods to poison packages
and
spread their malware
through the code supply chain.
Not all credit goes to the hackers, though — some npm security risks arise from the way the platform itself works, as with its
lagging efforts against typosquatting
, and, now, manifest confusion, Clarke said.
The problem is that npm doesnt automatically cross-reference a packages manifest — what users first see when they visit a package on the site — against its package.json, the standard file describing its contents. Both the manifest and package.json contain metadata including, crucially, what scripts and dependencies the package runs on.
It stands to reason, then, that they should agree with one another, but a publisher can simply manipulate a packages manifest, and npm wont notice. As a case in point, Clarke created an npm package with
a manifest
stripped of any evidence of the dependencies in
its package.json
.
Theoretically, hackers could do the same with their own packages, in order to conceal the existence of malware from unwitting software developers.
Clarke posited an historical precedent for manifest confusion. Before the node ecosystem became what it is today, he wrote, the number of people contributing to the corpus of software you trusted to use and download was very small. With a smaller community, you have more trust, and even as the npm registry was being developed, most aspects were open source and freely available to be contributed to and code inspected.
Even today, various references in docs.npmjs.com [point] to the fact that the registry stores the contents of package.json as the metadata — and nowhere does it mention that the client is responsible for ensuring consistency, Clarke explained.
Exactly why the system works this way isnt clear. At the time of publication, GitHub had not responded to Dark Readings request for comment.
[Who knows] the real reasons they chose to do validation client-side versus server-side? says Mike Parkin, senior technical engineer at Vulcan Cyber. It seems they chose to lean toward easier organic growth versus a path that would have given more security but would have impacted ease of use.
According to Clarke, GitHub has been aware of the manifest confusion weakness since at least Nov. 4 last year, and Clarke himself submitted a report on it March 9. However, GitHub closed that ticket and said they were dealing with the issue internally on March 21st, he lamented in his posting. “To my knowledge, they have not made any significant headway, nor have they made this issue public.”
But GitHub is understandably in a tough spot, he acknowledged. The fact that npmjs.com has functioned this way for over a decade means that the current state is pretty much codified.
Clarke, it may be noted, is the founder of an
alternative website for JavaScript packages, vlt
.
With no solution in sight, it will be up to developers to make sure theyre not downloading anything they dont realize is in a package. Clarke recommended that developers rely only on the metadata indicated by the packages contents, not its manifest, to account for any potential discrepancies.
To Parkin, taking care around third-party code needs to be mandatory practice for any developer and organization. Thats especially true with obscure libraries, or older ones that havent seen a lot of active development and may have been orphaned, or libraries that were recently added, he says. While none of those factors are immediate red flags that would preclude using them in a project, they are factors that make vetting the sources even more important.
It doesnt have to be difficult, though — plenty of vendors have been working on this problem for a while.
There are automated tools that can scan code for unusual features and obvious exploits, and those tools need to be part of the developers toolkit, Parkin says, pointing to
OWASPs list of source code analysis tools
.
Validating your packages should not be an optional step, he concludes. Instead, it should be built into any coding project that relies on third party libraries. Full stop.

Last News
▸ DHS-funded SWAMP scans code for bugs. ◂ Discovered: 23/12/2024 Category: security	▸ Debunking Machine Learning in Security. ◂ Discovered: 23/12/2024 Category: security	▸ Researchers create BlackForest to gather, link threat data. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Npm Plagued With Manifest Confusion Malware-Hiding Weakness