# Heap overflow happen when receiving short length key from ssh server using ssh protocol 1

PuTTY's SSH-1 login handler trusted server-supplied servkey/hostkey lengths, causing a heap buffer overflow when a malicious SSH-1 server sent a short key, enabling crash or RCE.

- Payout: $3,646
- Severity: high
- Program: PuTTY (European Commission - DIGIT)
- Credited: hey2baby
- Disclosed: 2019-09-20
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/630462
- Library page: https://bugbountylibrary.com/r/h1%3A630462
- Tags: domain:network impact:dos impact:rce kind:bounty platform:hackerone sev:high tech:linux technique:fuzzing technique:source-review vuln:memory-corruption vuln:rce

**Target:** PuTTY plink SSH-1 client, ssh1_login_process_queue
**Root cause:** ssh1_login_process_queue reads servkey and hostkey length fields from the server packet without validating them against the actual buffer, so a short length causes an out-of-bounds write past the allocated region.
**Steps:**
1. Patch OpenSSH 6.8p1 sshd.c/ssh-keygen.c to act as SSH-1 server sending short key lengths
2. Generate host key: `./ssh-keygen -t rsa1 -b 248 -f /tmp/ssh_host_rsa1_key`
3. Run patched sshd with protocol 1: `sshd -p 39000 -D -E aaaa -f sshd_config -b 248`
4. Build PuTTY with ASan: `./configure CFLAGS="-g -O0 -fsanitize=address" ...`
5. Connect: `./plink -1 -P 39000 root@localhost`
6. Observe ASan heap-buffer-overflow WRITE of size 1 just past a 31-byte region
**How found:** Code review of ssh1_login_process_queue revealed missing length validation on servkey/hostkey fields read from the server packet; confirmed by building a patched SSH-1 server to send short lengths and running an ASan-instrumented client.
**Exploitation:** Attacker controls a malicious SSH-1 server; on client connect it sends a crafted servkey/hostkey packet with a short length, triggering a one-byte heap overflow write in the client. Demonstrated as crash under ASan; RCE claimed as possible but not shown.
**Insight:** Legacy SSH-1 code paths in modern clients are rarely audited; server-controlled length fields in key-exchange packets are prime heap-overflow candidates—fuzz the pre-auth protocol-1 handshake of any client still supporting it.