# Memory disclosure in timegm

Out-of-bounds read in mruby's timegm when Time.new receives a month >11, leaking adjacent memory and crashing mirb.

- Payout: $1,000
- Severity: low
- Program: shopify-scripts
- Credited: volc
- Disclosed: 2017-01-31
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/192896
- Library page: https://bugbountylibrary.com/r/h1%3A192896
- Tags: domain:oss impact:data-leak impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:source-review vuln:dos vuln:info-disclosure vuln:memory-corruption

**Target:** mruby-time timegm (ext/mruby_engine/mruby-time/src/time.c)
**Root cause:** timegm loops `for (i=0; i<tm->tm_mon; ++i)` indexing static ndays[12] without validating tm_mon < 12, so attacker-controlled month reads past the array.
**Steps:**
1. Build mruby-engine mirb
2. Run `Time.new(1970, 0x10000)` (month=65536) in mirb
3. Observe OOB read of memory past ndays and segfault
**How found:** Code review of timegm noticed tm_mon is attacker-controlled and used as loop bound against a fixed 12-element array without bounds check.
**Exploitation:** Attacker supplies an out-of-range month to Time.new; the loop reads past the static ndays array, disclosing adjacent memory in the returned value and/or crashing the interpreter. Useful as an info leak to aid a separate exploit.
**Insight:** In embedded interpreters, audit C time/date conversion helpers where struct tm fields come straight from script arguments; month/day fields are classic unchecked array indices.