CVE-2024-24828 in pkg
Summary
by MITRE • 02/10/2024
pkg is tool design to bundle Node.js projects into an executables. Any native code packages built by `pkg` are written to a hardcoded directory. On unix systems, this is `/tmp/pkg/*` which is a shared directory for all users on the same local system. There is no uniqueness to the package names within this directory, they are predictable. An attacker who has access to the same local system has the ability to replace the genuine executables in the shared directory with malicious executables of the same name. A user may then run the malicious executable without realising it has been modified. This package is deprecated. Therefore, there will not be a patch provided for this vulnerability. To check if your executable build by pkg depends on native code and is vulnerable, run the executable and check if `/tmp/pkg/` was created. Users should transition to actively maintained alternatives. We would recommend investigating Node.js 21’s support for single executable applications. Given the decision to deprecate the pkg package, there are no official workarounds or remediations provided by our team. Users should prioritize migrating to other packages that offer similar functionality with enhanced security.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/03/2024
The vulnerability described in CVE-2024-24828 affects the pkg tool, a utility designed to bundle Node.js applications into standalone executables. This tool creates native code packages during the build process and stores them in a hardcoded directory on Unix systems at /tmp/pkg/*. The fundamental security flaw lies in the predictable naming convention and shared directory structure that allows any local user to manipulate the build artifacts. This represents a classic privilege escalation vulnerability where an attacker with local system access can substitute legitimate executables with malicious counterparts, creating a supply chain attack vector that exploits the trust model inherent in the packaging process. The vulnerability is categorized under CWE-276 as improper privileges and CWE-284 as improper access control, both of which fall under the broader category of privilege escalation and access control weaknesses.
The operational impact of this vulnerability is significant within local system environments where multiple users share the same machine. When a user executes a pkg-built application, the tool attempts to access the /tmp/pkg/ directory to retrieve native code components. An attacker who has already compromised local access can replace the legitimate native code files with malicious versions, effectively creating a persistent backdoor or injection point that executes with the privileges of the user running the application. This vulnerability aligns with ATT&CK technique T1554 as a component injection attack, where adversaries manipulate legitimate software components to gain persistence and execute malicious code. The predictable nature of the directory structure and file naming makes this attack surface particularly dangerous, as attackers can systematically target specific applications without requiring complex reconnaissance.
The deprecation of the pkg package exacerbates the security implications of this vulnerability, as no official patches or updates will be provided to address the issue. This leaves affected systems in a state of ongoing vulnerability without remediation options, forcing users into a reactive security posture. The recommended mitigation strategy centers on transitioning to actively maintained alternatives that have proper security considerations built into their design. The vulnerability demonstrates a critical gap in legacy software maintenance where deprecated tools continue to pose security risks without proper support or updates. Organizations should prioritize migration to modern Node.js versions that offer native support for single executable applications, such as Node.js 21's built-in capabilities, which eliminate the need for third-party tools with known security flaws. The absence of official workarounds or remediations underscores the importance of proactive security measures and the risks associated with using deprecated software components in production environments.