Skip to content

[BUG] CRITICAL: Memory Leak in Blob URL Management - Denial of Service Vulnerability #1427

@Puneet04-tech

Description

@Puneet04-tech

CRITICAL: Memory Leak in Blob URL Management - Denial of Service Vulnerability

Summary

Reframe has a critical memory leak vulnerability where blob URLs created during video processing are not consistently revoked, leading to unbounded memory growth and potential browser crashes. This violates the application's privacy promise by keeping user video data in memory indefinitely.

Vulnerability Details

Location

  • src/lib/ffmpeg.worker.ts line 87: Creates blob URL for FFmpeg core files but never revokes
  • src/lib/ffmpeg.ts line 113: Creates blob URL for export result but revocation depends on user action
  • src/components/VideoPreview.tsx line 77: Creates blob URL for video preview, cleanup only on unmount
  • src/hooks/useVideoEditor.ts line 16: Creates blob URL for metadata extraction, cleanup only on success/error

The Issue

  1. FFmpeg Core Files: The worker creates blob URLs for FFmpeg core files (JS, WASM, worker) but never revokes them. Each export creates new blob URLs that persist for the lifetime of the worker.

  2. Export Results: Export blob URLs are only revoked when:

    • User starts a new export
    • Component unmounts
    • Settings are reset
      If a user exports multiple times without these actions, blob URLs accumulate.
  3. Video Preview: Blob URLs are created for video preview but only cleaned up on component unmount. Rapid file changes without unmount cause accumulation.

  4. Metadata Extraction: Blob URLs for metadata extraction are only revoked on success/error. If the promise hangs (e.g., corrupted video), the URL leaks.

Attack Scenario

  1. Attacker uploads a specially crafted video that causes metadata extraction to hang
  2. Blob URL is created but never revoked
  3. Attacker repeats this process, consuming browser memory
  4. Browser becomes unresponsive or crashes (DoS)
  5. User loses all unsaved work

Impact

  • Memory Exhaustion: Each blob URL holds reference to potentially large video files (up to 2GB)
  • Browser Crash: Accumulated memory pressure can crash the browser tab
  • Data Loss: Unsaved work lost when browser crashes
  • Privacy Violation: Blob URLs persist in memory even after user navigates away, keeping user video data accessible in browser memory

Severity

CRITICAL - CVSS 7.5 (High)

  • Attack Vector: Local (user uploads malicious file)
  • Impact: High (memory exhaustion, DoS, privacy violation)
  • Privileges Required: None
  • User Interaction: Required (upload file)

Why This Matters

1. Privacy Betrayal

Reframe's core value is "100% private" processing. Memory leaks mean user video data persists in browser memory indefinitely, accessible to any script running in the same origin.

2. Denial of Service

Users can accidentally (or maliciously) cause browser crashes by processing multiple videos, making the application unusable.

3. Resource Exhaustion

Modern browsers have limits on blob URL storage. Exceeding these limits causes all blob operations to fail, breaking the entire application.

4. Non-Obvious

Memory leaks are insidious - they don't cause immediate failures. The application appears to work correctly until memory pressure builds up over time.

5. Hard to Debug

Memory leaks don't appear in error logs or crash reports. They manifest as "sluggish performance" or "random crashes" that are difficult to trace back to the root cause.

The Fix

Immediate Mitigation

// Track all blob URLs and revoke them systematically
let activeBlobUrls = new Set<string>();

function createTrackedBlobUrl(blob: Blob, mimeType: string): string {
  const url = URL.createObjectURL(blob);
  activeBlobUrls.add(url);
  return url;
}

function revokeAllBlobUrls(): void {
  activeBlobUrls.forEach(url => URL.revokeObjectURL(url));
  activeBlobUrls.clear();
}

// In worker cleanup
finally {
  revokeAllBlobUrls();
  for (const path of cleanupFiles) {
    await removeFile(path);
  }
}

Long-term Solution

  1. Implement automatic blob URL cleanup with WeakMap
  2. Add memory monitoring and warnings
  3. Implement blob URL lifecycle management
  4. Add cleanup on page visibility change
  5. Set maximum blob URL limits with graceful degradation

Why This Vulnerability Was Overlooked

  1. Browser API Design: URL.createObjectURL creates references that don't automatically clean up
  2. No Immediate Symptoms: Leaks accumulate over time, not immediately
  3. Testing Gap: Unit tests don't measure memory usage over time
  4. Complex Lifecycle: Blob URLs created in multiple contexts (worker, main thread, components)
  5. Error Path Neglect: Cleanup logic often only tested in success paths

This issue should be prioritized as it directly impacts:

  • Application stability (browser crashes)
  • User privacy (data persistence in memory)
  • Resource management (memory exhaustion)
  • User experience (performance degradation over time)

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions