# [tor] libevent dns remote stack overread vulnerability

libevent DNS name_parse lacks bounds check before memcpy, letting crafted compression-pointer jumps cause a 63-byte stack overread in Tor's resolver.

- Payout: hidden
- Severity: medium
- Program: Tor
- Found by: guido
- Disclosed: 2017-10-19
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/112632
- Library page: https://bugbountylibrary.com/r/h1%3A112632
- Tags: area:devices domain:network impact:dos kind:bounty platform:hackerone sev:medium tech:linux technique:source-review vuln:dos vuln:memory-corruption

**Target:** libevent DNS name_parse / Tor DNS resolver
**Root cause:** Before memcpy at line 976, the code never verifies that packet+j+label_len stays within the packet buffer length; compression-pointer jumps can position j at the buffer end.
**Steps:**
1. Build libevent with `CFLAGS="-fomit-frame-pointer -fsanitize=address" ./configure && make -j4`
2. Run `cd samples && ./dns-example -servertest`
3. Send crafted DNS response via `python libevent-poc.py` that uses compression pointers (label_len & 0xc0) to jump j to the end of the packet
4. Observe ASan stack-buffer-overflow READ of size 1 in name_parse
**How found:** Code review of name_parse: noticed GET8/GET16/GET32 macros bounds-check but the memcpy at line 976 does not check packet+j+label_len against length, and pointer-jump loop lets j reach the buffer end.
**Exploitation:** Attacker controls a DNS response; repeated compression-pointer jumps advance j to the packet end, then a label_len up to 63 triggers memcpy reading past the buffer. Overread only, no overwrite; may crash the resolver.
**Insight:** In DNS name parsers, compression-pointer loops reset j to arbitrary offsets; check that each label's memcpy source range stays in-bounds, not just the pointer target offset.