Addressing the npm Manifest Confusion Vulnerability

A potential security risk in the npm ecosystem known as “manifest confusion” has recently been spotlighted in a blog post by Darcy Clarke, a former Staff Engineering Manager at GitHub.

Clarke mentioned that JFrog Artifactory seems to replicate this issue, so of course we investigated it right away. In this post, we will explain what the issue is and what it might mean for JFrog Artifactory users.

What is Manifest Confusion?

“Manifest confusion” refers to the fact that in the npm ecosystem, a package’s manifest and its tarball are published independently. They are never fully validated against each other, making it possible for threat actors to declare falsified metadata and dependencies while hiding the true and potentially malicious packages nested within the tarball without the user’s knowledge.

The npm Registry has historically trusted the npm client for data validation, and this vulnerability potentially opens the door to misuse.

This issue isn’t limited to the npm Registry but also affects any 3rd party tool or platform that references the metadata from the public npm Registry.

How is JFrog Artifactory Impacted by this?

JFrog Artifactory provides three main types of npm repositories: local, remote, and virtual. Local repositories are not impacted by this issue, but remote and virtual repositories might be impacted by it. Local repositories are usually used for in-house organization packages, while remote repositories serve to proxy and cache package dependencies from public registries. Virtual repositories aggregate both local and remote repositories to a centralized access point for easy use.

Local Repositories Are Not Affected

First and foremost, if you are using Artifactory’s local npm repositories you are not affected by this vulnerability, as JFrog Artifactory indexes and stores each package according to its actual package.json information and not based on the manifest metadata file. This ensures that package names and versions are stored according to the actual content, preventing you from downloading any unwanted packages under a falsified name. Attempts to install the falsified package name will result in failure.

With that being said, we did notice that since we do not enforce package path names in our npm repositories, the “manifest confusion” method actually creates a “path confusion” issue as the location of your stored package will be under the incorrect package name declared in the manifest file.

This can cause some confusion when searching visually for a package in the artifacts tree, however, since the path is only a location and not the package name, you will not be able to search or find a package under the falsified name in the WebUI, CLI, or REST API. This distinction ensures that you will not be able to download a package you did not intend to.

Please note that our team is working on a solution that will be available shortly, allowing you to opt-in to enforce the path layout according to your package name.

Remote And Virtual Repositories Are affected

The situation is different when it comes to remote repositories since JFrog Artifactory serves exactly what the 3rd-party registry declares. One of the core assumptions of any integration is that the 3rd-party REST API declares truthfully and accurately what you are fetching.

Since the “Manifest Confusion” vulnerability can be exploited directly on any 3rd-party registry that does not validate using the tarball, Artifactory cannot ensure the truthfulness of the content it is proxying.

Furthermore, virtual repositories can aggregate content from multiple local and remote repositories, meaning that the vulnerabilities affecting remote repositories transfer to virtual repositories.

Customers relying on npm virtual repositories need to be particularly cautious and take appropriate measures to protect their software supply chain until the contents of the 3rd-party registries are verified, as JFrog does with our local repositories.

What can be done?

Since the impact is applicable mainly to remote and virtual repositories, we recommend adopting the following “good development paradigms” to minimize your risks:

• Set Proper User Permissions – In Artifactory the ability to fetch new packages from remote registries is allowed only by users that have a “Deploy” or “Admin” permissions. By limiting your deployment level permission to the appropriate users (preferably automations only), you ensure that no one with a “Read only” permission can pull an unvalidated package from a remote registry. Please note that “Read only” users are allowed to pull packages that have already been stored in the remote repository cache.
• Use Priority Resolution – The Priority Resolution feature allows you to define “first look” priority to selected local and remote repositories. When a user runs an Install command, Artifactory will search for a matching package only within the scope of the repositories with the Priority Resolution checkbox selected. You can use this feature to ensure resolution only happens from your approved local repositories or Smart Remote repositories” (a remote pointing to a local repository). Please note that if you try to install a package that does not exist in your list of priority remote repositories, Artifactory will failover and continue to search for matching packages in your remote cached repositories.
• Use Curation Policies – JFrog Curation allows you to define policies to automatically block or approve OSS packages before entering your software supply chain. Curation seamlessly identifies known malicious or risky packages to prevent consumption in any software pipeline and/or flagging those that need review. For further details please see JFrog Curation.

Next Steps

We have added the ability to enforce the package name on the artifact path in local npm repositories. This allows you to enforce the package layout for all npm repositories on your JFrog Artifactory instance and will prevent users from uploading packages to a path that does not match your package name.

To enforce Artifactory to read the artifact path, set the following system property: artifactory.npm.enforce.path=true

For more information, see System Properties >
Note: this capability is available from Artifactory Versions 7.63.5 and 7.64.4 and above.

Conclusion

The npm vulnerability has raised concerns about the integrity and security of packages within the npm ecosystem. While Jfrog Artifactory’s local repositories remain unaffected, there are some minor user interface issues that could cause some confusion around where you stored your package.

However, the real impact is felt in remote and virtual repositories, as they serve exactly what 3rd-party registries declare. This can potentially expose customers to compromised or malicious packages.

To mitigate these risks, we suggest that you audit your user permissions and limit the number of users with permissions higher than “Deploy”. Additionally, incorporate the  Priority Resolution feature to  ensure packages are installed from your local repositories and trusted remote repositories.