# Crash: A call to Symbol.new leads to a crash when inspecting the resulting object

Calling Symbol.new in mruby creates a malformed Symbol object whose inspect dereferences a null name pointer, crashing the interpreter.

- Payout: $1,000
- Severity: low
- Program: shopify-scripts
- Credited: brakhane
- Disclosed: 2016-12-16
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/185957
- Library page: https://bugbountylibrary.com/r/h1%3A185957
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby engine Symbol class (Symbol.new / inspect)
**Root cause:** Symbol is exposed as a normal class allowing Symbol.new, producing a Symbol object with no valid name; sym_inspect then calls strlen on a NULL name pointer. Related to the underlying boxing model.
**Steps:**
1. Run `a = Symbol.new` in mirb/sandbox
2. Call `a.inspect` (mirb auto-inspects each statement)
3. Observe SIGSEGV in sym_inspect at symbol.c:411 on strlen(NULL)
**How found:** Noticed Symbol.new was callable unlike Ruby 2.3 (NoMethodError), suspected boxing model issue from prior ticket #185794, and confirmed crash via inspect in mirb; noted other singleton classes remove new via mrb_undef_class_method.
**Exploitation:** Attacker-supplied mruby script executed in the sandbox calls Symbol.new then inspect, crashing the interpreter process (DoS).
**Insight:** In embedded interpreters, check whether singleton/special classes (Symbol, TrueClass, NilClass) still expose `new`; constructing them yields objects with NULL internal fields that crash on inspect/strlen.