Skip to content

Latest commit

 

History

History
23 lines (15 loc) · 2.52 KB

File metadata and controls

23 lines (15 loc) · 2.52 KB

Attack Surface Analysis for addaleax/natives

  • Description: Exploiting dynamic module loading by manipulating the module name to load unintended or malicious modules. This occurs when the module name is derived from untrusted sources.

  • How natives Contributes: natives provides the require() function that accepts a string as input to load built-in Node.js modules. If this string is constructed from untrusted input, natives becomes the direct entry point for this vulnerability, enabling the exploitation of dynamic module loading.

  • Example: An application uses user input to determine which native module to load via natives.require(). An attacker injects the module name "child_process" when the application was only intended to load "os". This allows the attacker to access the powerful child_process module, enabling arbitrary command execution on the server.

  • Impact:

    • Arbitrary Code Execution: Accessing modules like child_process or vm allows an attacker to execute arbitrary code on the server, leading to complete system compromise.
    • Information Disclosure: Accessing modules like process can reveal environment variables, process IDs, and other sensitive information, potentially aiding further attacks.
    • Denial of Service: Loading unexpected modules or causing errors during module loading could lead to application crashes or denial of service.
  • Risk Severity: Critical

  • Mitigation Strategies:

    • Input Sanitization and Validation: Strictly validate and sanitize all input used to construct module names before passing them to natives.require(). Assume all external input is malicious.
    • Whitelist Allowed Modules: Implement a strict whitelist of explicitly allowed native module names. Only load modules that are on this whitelist. Reject any module name not on the whitelist.
    • Avoid Dynamic Module Names from Untrusted Sources: Refactor code to completely avoid deriving module names from user input or external, untrusted data sources. Use predefined, static module names whenever possible. If dynamic loading is absolutely necessary, carefully control the source of module names and apply robust validation.
    • Principle of Least Privilege: Only load the absolutely necessary native modules. Avoid loading modules speculatively or unnecessarily. Minimize the number of modules on the whitelist.