# [tor] pre-emptive defenses, potential vulnerabilities

Integer truncation and multiplication overflows in Tor's write_escaped_data, base64_decode, and do_getpass cause heap/stack buffer overflows on 32-bit and 64-bit systems.

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

**Target:** Tor control protocol getinfo/networkstatus handlers and base64 decoder
**Root cause:** Signed/unsigned truncation in loop bound `i<(int)len` skips newline counting for len>=0x80000000, and `(srclen*3)/4` multiplies before dividing, overflowing for large srclen; both under-size output buffers.
**Steps:**
1. Compile PoC: `gcc -fsanitize=address -fomit-frame-pointer write_escaped_data.c; ./a.out 1`
2. For 32-bit overflow: `gcc -m32 -fsanitize=address -fomit-frame-pointer write_escaped_data.c; ./a.out 2`
3. For base64: `gcc -m32 -fsanitize=address -fomit-frame-pointer base64_decode.c; ./a.out`
4. For do_getpass: `gcc -fomit-frame-pointer -fsanitize=address do_getpass.c` then run with progressively shorter prompt strings
**How found:** Code review of allocation-size arithmetic: noticed `i<(int)len` truncation, multiply-before-divide in base64 length check, and a `memset`/`memcpy` size mismatch in do_getpass where p2len can exceed the allocated strlen(prompt)+1.
**Exploitation:** Not demonstrated remotely; author states reliable remote attack is hard because write_escaped_data input comes from intricate getinfo/networkstatus aggregation paths. PoCs show ASan heap/stack overflows locally.
**Insight:** Audit size-computation expressions for signed truncation (`(int)len`) and multiply-before-divide ordering; also check that memset/memcpy lengths are bounded by the actual allocation, not a separately computed max.