Security: Worker loading fallback uses fetch with potentially controllable basePath

[evmparser]

🔒 Security Problem

The changeLoadingWorker plugin in config/vite.replace.js includes a fallback mechanism that uses fetch() to dynamically load worker scripts from a basePath variable.

File: config/vite.replace.js (line 12)

Vulnerable code pattern:

// Fallback mechanism that fetches worker code
fetch(basePath + '/workerHelpers.js')
  .then(response => response.text())
  .then(code => {
    // Execute the fetched code in worker context
  })

🚨 Security Impact

If an attacker can control or manipulate the basePath variable, they could:

Critical Risks:

• Arbitrary Code Execution: Load and execute malicious JavaScript code in the worker context
• Cryptographic Operation Compromise: Since this is an FHE (Fully Homomorphic Encryption) SDK, malicious worker code could:
  • Intercept and exfiltrate encryption keys
  • Tamper with cryptographic operations
  • Leak sensitive encrypted data
  • Break the security guarantees of the FHE system
• Supply Chain Attack: If basePath can be manipulated during build or runtime, this becomes a supply chain vulnerability
• Cross-Site Scripting (XSS): Attackers could inject malicious worker scripts from external domains

Attack Scenarios:

1. Path Traversal: basePath = "https://evil.com/" loads malicious worker code
2. Environment Variable Injection: If basePath is derived from environment variables
3. Build-Time Compromise: Malicious build scripts could modify basePath
4. Runtime Manipulation: If basePath is exposed to client-side code

Why This Is Critical for an Encryption SDK

For a cryptography SDK like relayer-sdk, code integrity is paramount:

• Users trust this SDK to handle sensitive cryptographic operations
• Any code execution vulnerability can completely break security guarantees
• FHE operations are complex and difficult to audit - malicious code could hide within them
• This could affect all downstream users of the SDK

Recommended Fixes

1. Use Static, Embedded Worker Code (Best)

// Embed worker code directly instead of fetching
const workerCode = `
  // Inline worker code here
`;
new Worker(URL.createObjectURL(new Blob([workerCode])));

2. Validate and Sanitize basePath

// Ensure basePath is from a trusted, static source
const TRUSTED_BASE_PATH = '/dist'; // Hardcoded, not dynamic
const safePath = TRUSTED_BASE_PATH + '/workerHelpers.js';

3. Use Subresource Integrity (SRI)

// Verify the integrity of fetched worker code
const expectedHash = 'sha384-...'; // Known hash of legitimate worker code
fetch(url).then(response => {
  // Verify hash before executing
});

4. Implement Content Security Policy (CSP)

<!-- Restrict worker-src to same origin only -->
<meta http-equiv="Content-Security-Policy" 
      content="worker-src 'self'; script-src 'self'">

5. Code Review Required

• Audit how basePath is determined
• Verify it cannot be influenced by user input or environment variables
• Ensure the worker loading mechanism uses only trusted sources

Immediate Actions

1. 🔍 Audit the code: Determine exactly how basePath is set
2. 🔒 Harden the mechanism: Implement one or more of the suggested fixes above
3. 🧪 Test: Verify that worker loading cannot be exploited
4. 📝 Document: Clearly document the security assumptions around worker loading
5. 🔐 Consider: Should worker code be embedded to eliminate fetch entirely?

Context

This issue was identified as part of a comprehensive configuration audit of the relayer-sdk. Given the cryptographic nature of this SDK, security vulnerabilities in the build and loading process are critical and must be addressed with high priority.