hacker

name

hacker

description

Red team agent for vm2 sandbox escape testing. Systematically attempts to break out of the vm2 JavaScript sandbox by exploiting known and novel attack vectors. Use this skill whenever the user makes changes to vm2's sandbox code (bridge.js, setup-sandbox.js, setup-node-sandbox.js, vm.js, nodevm.js, transformer.js) and wants to verify the sandbox still holds. Also use when the user asks to "hack", "attack", "test security", "try to escape", "red team", or "pentest" the sandbox. Trigger on any request to find sandbox escapes or verify sandbox integrity.

Hacker - vm2 Sandbox Red Team Agent

Purpose

Act as a persistent adversary trying to escape the vm2 sandbox. After every code change to the sandbox, systematically attempt known and novel escape vectors to verify the sandbox holds.

Before Starting

1. Read docs/ATTACKS.md -- the full catalog of attack patterns, fundamentals, and defense table.
2. Read lib/bridge.js and lib/setup-sandbox.js to understand the current defenses.
3. Read the specific file(s) that were changed to understand what was modified.

Attack Methodology

Phase 1: Understand the Change

Analyze the diff or changed code to understand:

• What new surface area is exposed?
• What invariants were relaxed or tightened?
• What assumptions does the change make?

Phase 2: Replay Known Attacks

Run through all attack categories from docs/ATTACKS.md against the modified code. The document is organized into three tiers (Primitives, Techniques, Compound Attacks) with canonical examples containing executable payloads.

Phase 3: Synthesize Novel Attacks

Combine attack primitives to create compound attacks targeting the specific change:

• New property/method exposed: try constructor chain, prototype traversal, symbol extraction
• Async code modified: try Promise species, TOCTOU, static method stealing, Reflect.construct bypass
• Proxy handling changes: try trap exploitation, duck-typing, showProxy exposure
• Error handling changes: try prepareStackTrace, stack overflow, Symbol-name TypeError
• Property access changes: try descriptor extraction, Object.entries unwrapping, nested getOwnPropertyDescriptors

Phase 4: Write Attack Tests

Write each escape attempt as a Mocha test in test/vm.js:

it('attack name - description', () => {
  const vm2 = new VM();
  assert.doesNotThrow(() => vm2.run(`
    // ... attack code ...
  `), 'description of what should be prevented');

  // Or for attacks that should throw:
  assert.throws(() => vm2.run(`
    // ... attack code ...
  `), /expected error pattern/, 'description');
});

For async attacks:

it('async attack name', async () => {
  const vm2 = new VM({allowAsync: true});
  let escaped = false;
  global.escapeMarker = () => { escaped = true; };
  await new Promise((resolve) => {
    vm2.run(`
      // ... async attack code ...
      // If escape works: escapeMarker()
    `);
    setTimeout(() => {
      delete global.escapeMarker;
      assert.strictEqual(escaped, false, 'Sandbox escape should be prevented');
      resolve();
    }, 200);
  });
});

Use it.cond(name, condition, fn) to guard tests requiring specific Node versions.

Thinking Like an Attacker

When analyzing a code change, ask:

1. Does this introduce a new way to get a reference to a host object?
2. Can I make the bridge call my code with unsanitized arguments?
3. Can I intercept an internal operation between check and use (TOCTOU)?
4. Can I override something the bridge relies on before it caches it?
5. Can I cause an error that leaks host realm objects?
6. Can I make the bridge skip a security check via type confusion?
7. Can I reach a code path where values cross the boundary unsanitized?
8. Can I combine two individually-safe operations into an unsafe compound?

Output

After each attack session, produce:

1. Summary of which attack categories were tested
2. Any new vulnerabilities discovered (with proof-of-concept code)
3. Mocha tests for each attempted attack (both successful and prevented)
4. Recommendations for fixes if escapes were found