S04:2023 - Vulnerable and Outdated Components 📦🔍

Overview

Snaps present a valuable target for supply chain-based attacks. If a malicious actor successfully undermines the security of a direct or nested dependency within a Snap, there is a potential risk of compromising keys or essential functionality. Given the elevated risk associated with supply chain attacks on wallet extensions, this vulnerability is ranked at #4 in the Snap Security Top 10.

Description

Vulnerable and outdated components refer to software libraries or modules that are no longer actively maintained or have known security vulnerabilities. Incorporating such components into the Snap can expose it to a range of potential exploits, including data breaches, remote code execution, and other security compromises. To maintain a robust security posture, it is crucial to proactively manage and update all components, ensuring they meet the latest security standards.

• Failure to have comprehensive knowledge of the versions of all utilized components.
• Use of outdated, vulnerable, or unsupported libraries.
• Lack of processes for regularly scanning for vulnerabilities (CI/CD pipeline).
• Lack of processes for keeping up to date with security bulletins.
• Lack of risk management process concerning security patch management.
• Incomplete compatibility testing with Software developers not rigorously testing the compatibility of updated, upgraded, or patched libraries, risking potential integration issues or unforeseen vulnerabilities.
• Failing to retire or replace components that have reached their end-of-life, leaving the application susceptible to unpatched vulnerabilities and diminishing long-term security.
• Ineffective or nonexistent version pinning.
• Missing package manager lockfile.
• Closed source or local dependencies not commited with the code repository.

How to Prevent

• Utilize version pinning to ensure that only approved and secure versions of components are utilized.
• Check for exact version pinning (version 0.0.0 without ^) and provide the package managers lockfile with the code repository enforcing reproducibility and allowing local integrity checks and exact dependency tree versioning.
• Ensure the repository builds and all depdendencies are available. Avoid using opaque dependencies or dependencies that are only distributed as compiled/minified non-human readable versions.
• Conduct regular audits of all third-party components used in the extension to identify vulnerabilities or deprecated versions.
• Leverage automated tools for dependency scanning to streamline the identification of outdated or insecure components.
• Subscribe to security mailing lists or notifications provided by component vendors to stay informed about the latest security updates and patches.
• Act promptly on security alerts, prioritizing the resolution of critical vulnerabilities.
• Regularly update dependencies to their latest, stable versions, incorporating security patches and performance improvements.
• Establish a process for timely testing and integration of dependency upgrades into the extension codebase.
• Implement fallback mechanisms to handle scenarios where immediate upgrades are not feasible, ensuring the continued security of the extension during the upgrade process.

Example Misuse Scenarios

Scenario #1: Supply Chain Attacks

Malicious actors may compromise the build or distribution process of third-party components, introducing backdoors or malicious code into the extension.

• In the following example, developers failed to pin the exact versions (^0.0.0) and hashes of the 3^rd party components used in their build process. With the next build, components are updated and the malicious code is included in the next build, compromising the Snap.

  "dependencies": {
     "@metamask/key-tree": "7.1.1",
     "@metamask/snaps-ui": "0.32.2",
     "iso-base": "^1.0.0",             // INSECURE <-- not an exact version pin
     "iso-filecoin": "^0.2.3",          // INSECURE <-- not an exact version pin
     "merge-options": "3.0.4",
     "zod": "3.21.4"
  },
  

• Furthermore, it is recommended to commit the package managers lockfile (e.g. npm) to the code repository to allow integrity checks on dependencies. Here's a truncated example for pnpm-lock.yaml importing @metamask/key-tree with version pinning and integrity hashes:

  lockfileVersion: '6.0'
  
  settings:
  autoInstallPeers: true
  excludeLinksFromLockfile: false
  
  importers:
  
  packages/snap:
     dependencies:
        '@metamask/key-tree':
        specifier: ^7.1.1
        version: 7.1.1
  
  
  packages:
  
  /@metamask/key-tree@7.1.1:
     resolution: {integrity: sha512-D9mvbb7M/wGyC26TKzeS29rif4UX0yMN2Ws8/YdxY1wYE6udDvmyE6fFR7UGwJx9EGsPrqLmtqrbs5qKoyDNow==}
     engines: {node: '>=16.0.0'}
     dependencies:
        '@metamask/scure-bip39': 2.1.0
        '@metamask/utils': 6.1.0
        '@noble/ed25519': 1.7.3
        '@noble/hashes': 1.3.1
        '@noble/secp256k1': 1.7.1
        '@scure/base': 1.1.1
     transitivePeerDependencies:
        - supports-color
  

Scenario #2: Exploitation of Known Vulnerabilities

Attackers may exploit known vulnerabilities in outdated components to compromise the integrity and security of the Snap.

Scenario #3: Zero-Day Exploits

The use of outdated components increases the risk of falling victim to zero-day exploits, where attackers target undisclosed vulnerabilities for which no patches are available.