Deno CLI Vulnerability Repeats npm mistakes: CVE-2024-37150

As a Node.js developer, staying on top of security vulnerabilities is crucial. Today, we’re diving into a recent security issue that affects the Deno CLI - CVE-2024-37150. This vulnerability is a stark reminder of how seemingly minor oversights can lead to significant security risks. Let’s break it down and see what we can learn from it.

What’s the Deal with CVE-2024-37150?

Picture this: you’re sipping your morning coffee, ready to tackle some Deno development, when suddenly you hear about a vulnerability in Deno 1.44.0. Your first thought might be, “Oh no, not another one!” But don’t panic just yet. Let’s understand what’s going on. The issue revolves around how Deno handles .npmrc support. In simple terms, Deno was a bit too trusting when it came to sending credentials. It would send .npmrc credentials for a scope to the tarball URL, even when the registry provided URLs for a tarball on a different domain.

Who’s Affected?

If you’re using Deno 1.44.0 and relying on .npmrc, you might want to pay attention. This vulnerability potentially affects:

• Users of the deno install subcommand
• Those using auto-install for npm: specifiers
• Developers utilizing LSP (Language Server Protocol)

Breaking It Down: The Technical Nitty-Gritty

Let’s get our hands dirty with some technical details. Imagine we’re looking at a package on the npm registry:

https://registry.npmjs.org/code-block-writer

Under the hood, this URL contains information about the package, including where to find the tarball:

{
  "versions": {
    "<version>": {
      "dist": {
        "tarball": "https://registry.npmjs.org/code-block-writer/-/code-block-writer-1.0.0.tgz"
      }
    }
  }
}

Here’s where things get tricky. Deno was only looking at the first URL (https://registry.npmjs.org/code-block-writer) to decide where to send credentials. It didn’t consider that the tarball URL could be completely different.

In other words, Deno would happily send your https://registry.npmjs.org/ credentials to whatever URL was specified for the tarball. Yikes!

The npm CLI Connection: A Similar Tale

Interestingly, this isn’t the first time we’ve seen this kind of issue. The npm CLI had a similar vulnerability in the past. They called it the “No auth for URI, but auth present for scoped registry” problem. Here’s a quick example of what the npm CLI warning looked like:

npm WARN registry No auth for URI, but auth present for scoped registry.
npm WARN registry
npm WARN registry URI: http://my.private.tarball.host.com/foo/bar/baz
npm WARN registry Scoped Registry Key: //my.private.registry.host.com/registry/path/
npm WARN registry
npm WARN registry More info here: https://github.com/npm/cli/wiki/No-auth-for-URI,-but-auth-present-for-scoped-registry

The npm team fixed this by changing how they handle authentication. Now, auth information is strictly bound to a specific registry, and only requests for URIs under that registry’s base URI will receive the auth.

Fixing the Vulnerability: What You Need to Do

If you’re using Deno, here’s your action plan:

• Upgrade to Deno 1.44.1: This version addresses the vulnerability.
• Rotate Your Registry Credentials: If your private registry serves tarballs from a different domain, it’s time to change those credentials.

If you’re curious, here’s the Deno commit that fixed this security issue CVE-2024-37150.

For npm users who might be dealing with similar issues, you might need to update your .npmrc file. Here’s an example:

@my-company:registry = https://my.private.registry.host.com/registry/path/
//my.private.registry.host.com/registry/path/:_authToken = some-authentication-token
//my.private.tarball.host.com/:_authToken = some-authentication-token

This ensures that the auth token is sent to both the registry and the tarball host.

Lessons Learned: Security is in the Details

This vulnerability serves as a crucial reminder: security often lies in the smallest details. As Node.js developers, we need to be vigilant about how our tools handle authentication and data transmission. Here are some key takeaways:

• Always keep your tools updated: Regular updates often include critical security patches.
• Understand your dependencies: Know how your tools interact with registries and handle credentials.
• Implement the principle of least privilege: Only send credentials where they’re absolutely necessary.
• Stay informed: Keep an eye on security bulletins and updates from the tools you use.

Remember, in the world of development, a small oversight in credential handling can lead to significant security risks. Stay alert, stay updated, and keep coding securely!

The Deno CLI vulnerability (CVE-2024-37150) is a wake-up call for all of us in the Node.js community. It reminds us that even well-established tools can have security flaws, and it’s our responsibility to stay informed and act swiftly when vulnerabilities are discovered. Keep your Deno CLI updated, review your .npmrc configurations, and always prioritize security in your development practices.