The NPM package with 3 million weekly downloads had a serious vulnerability


The NPM package with 3 million weekly downloads had a serious vulnerability

fake images

The popular “pac-resolver” NPM package has fixed a severe remote code execution (RCE) flaw.

The pac-resolver packet receives more than 3 million weekly downloads, extending this vulnerability to Node.js applications that depend on open source dependency. Pac-resolver promotes itself as a module that accepts JavaScript proxy configuration files and generates a function for your application to assign certain domains to use a proxy.

Be a proxy or not a proxy

This week, developer Tim perry revealed a high severity flaw in pac-resolver that can allow threat actors on the local network to execute arbitrary code within your Node.js process every time it tries to make an HTTP request.

By adding proxy support to your HTTP Toolkit, Perry began auditing the pac-resolver code and came across the security issue. Follow up as CVE-2021-23406, the vulnerability has to do with the way the module processes proxy automatic configuration (PAC) files. PAC files consist of JavaScript code that specifies a proxy setting: which network requests should go through a proxy, and which should go directly out. For example, in a PAC file, network administrators can explicitly specify a network proxy through which all traffic should be routed and show the domains that are exempt from the requirement:

function FindProxyForURL(url, host) {
// Send all *.example requests directly with no proxy:
if (dnsDomainIs(host, '.example.com')) {
return 'DIRECT';
}

// Send every other request via this proxy:
return 'PROXY proxy.example.com:8080';
}

In the example above, network requests to “example.com” will bypass the proxy, while all other traffic will be directed to go through a proxy server.

Originally introduced as part of Netscape Navigator 2.0 in 1996, the PAC standard it is still relevant and in widespread use today. For example, Web Proxy Auto-Discovery Protocol (WAPD) uses DNS and / or DHCP services to locate PAC files on a network and import proxy settings into an application. However, as proxy configurations get larger, the JavaScript code in a PAC file can become increasingly complex and is ideally designed to run in a virtualized environment (VM).

Few lines of JavaScript can bypass the VM and lead to RCE

And that’s where the problem begins.

For example, a related NPM package called Pac-Proxy-Agent, which was created by the same author and has more than 2 million weekly downloads, provides PAC file support for Node.js applications. Pac-Proxy-Agent does this by taking the URL of a PAC file, retrieving the file, and then acting as a Node.js HTTP agent that handles outgoing requests for your application. But Pac-Proxy-Agent fails to sandbox PAC files correctly because it uses the vulnerable pac-resolver module, which also relies on “degenerator” to build the PAC function.

Degenerator is another package of the same author which helps to transform arbitrary code into a sandboxed function using Node.js’ “VM” module. But the VM module was never designed to be used as a security mechanism, something that is explicitly spelled in the Node.js docs. Therefore, the output of degenerator, when used by a chain of packets such as pac-resolver, Pac-Proxy-Agent, and proxy-agent, presents a security risk.

Referring to a disclaimer in the Node docs that says: “The vm module is not a security mechanism. Do not use it to run untrusted code”, Perry said in a blog post, “This is an easy mistake to make: it’s small text (frankly, it should be the title of that page and next to each method) and MongoDB did the exactly the same also in 2019, with even worse consequences. “

Perry further explained that “this creates a big problem. While the VM tries to create an isolated environment in a separate context, there is a long list of easy ways to access the original context and get out of the sandbox entirely … allowing the code inside the ‘sandbox’ to do basically whatever you like on your system. “

With that, Perry shared proof-of-concept exploit code that demonstrates how an attacker can get out of the virtual machine:

“That’s it, this is all that is required to get out of the VM module sandbox. If you can make a vulnerable target use this PAC file as their proxy configuration, then you can run arbitrary code on your machine,” he explained.

The vulnerability seriously affects those who use versions of pac-resolver prior to 5.0.0, even transitively in their Node.js application, and:

  • Explicitly use PAC files for proxy settings or
  • Read and use the operating system proxy settings in Node.js on systems with WPAD enabled or
  • Use proxy settings (env vars, configuration files, remote configuration endpoints, command line arguments) from an untrusted source

A remote attacker can, in any of these scenarios, configure a malicious PAC URL and run arbitrary code on a computer each time an HTTP request is made using proxy settings.

The solution for pac-resolver in version 5.0.0 simply consists of hitting Degenerator version to 3.0.1. The kernel fix went into the degenerator itself and implements a stronger solution. sandboxing mechanism via the vm2 module to “avoid privilege escalation of untrusted code”.

Perry thanked Snyk for supporting the developer throughout the coordinated vulnerability disclosure process.

Affected developers must upgrade to pac-resolver version 5.0.0 or higher to correct this serious vulnerability in their applications.




arstechnica.com

Leave a Reply

Your email address will not be published.