# Range#initialize_copy null pointer dereference

Removing Range#initialize_copy in mruby lets dup/clone build an uninitialized Range, and any instance method then null-derefs and segfaults the sandbox.

- Payout: $10,000
- Severity: high
- Program: shopify-scripts
- Credited: h72
- Disclosed: 2016-12-17
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/181685
- Library page: https://bugbountylibrary.com/r/h1%3A181685
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:high tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby Range object lifecycle via mruby-engine sandbox
**Root cause:** dup/clone allocate the object then call initialize_copy to populate internal state; removing Range#initialize_copy leaves the new Range uninitialized, so instance methods dereference a null pointer.
**Steps:**
1. Run `Range.remove_method(:initialize_copy)` then `(1..2).dup.to_s` in mruby
2. Or via engine: `MRubyEngine.new(512*1024, 1000, 1000).sandbox_eval("/tmp", %{ Range.remove_method(:initialize_copy); (1..2).dup.to_s })`
3. Observe segfault from null pointer dereference on the uninitialized Range
**How found:** Reasoned about dup/clone semantics: they allocate then call initialize_copy to copy internal state, so removing that method should yield an uninitialized object; tested calling an instance method on it to confirm the null deref.
**Exploitation:** Attacker submits the two-line script to the sandboxed mruby engine; removing the method and duping a Range produces an uninitialized object whose method call segfaults the interpreter, crashing the sandbox process.
**Insight:** In embedded interpreters, look at object lifecycle hooks (initialize_copy, dup, clone) that can be removed or overridden from within the sandbox to produce partially-initialized objects that later crash on method dispatch.