davide
65c515bf7a
A hostile server could stream an endless line with no newline and exhaust the client's memory. A single reply is now capped at 16 MiB (configurable via maxLineBytes in ConnectAsync); on excess the connection fails with InvalidDataException. See ADR 0035.
1.7 KiB
1.7 KiB
0035. Cap the length of a server line
- Status: Accepted
- Area: Network
- Recorded: 2026-11-03
Context
ElectrumClient.ReadLoopAsync accumulated bytes until it found a newline, with no maximum. A malicious, misconfigured or compromised server could send an endless line and drive memory use up until the process died, which is cheap to do and fatal on Android. SECURITY.md treats denial of service against the indexing server as out of scope, but here it is the client that dies, and the fix is small.
Decision
- A single JSON-RPC line is capped at
ElectrumClient.DefaultMaxLineBytes(16 MiB), a parameter ofConnectAsync(maxLineBytes). The default is well above the largest legitimate replies: header batches (a few hundred KB), a large transaction (up to about 2 MB of hex) and the history of a very active address (a few MB). - The check runs as the buffer grows, before a newline arrives, and also on complete lines, so neither an unterminated stream nor one huge terminated line is buffered past the cap (apart from what a single read delivers).
- On excess the read loop fails with
InvalidDataException. This reuses the protocol-error path: pending requests fail with that exception, the connection is marked dead,Disconnected(ex)is raised and later requests fail fast.
Consequences
- One hostile server can no longer exhaust the memory of the client with an unbounded line.
- A legitimate reply larger than 16 MiB would be refused; none is expected on this chain, and the cap is a parameter.
- No new parser is introduced, so no new fuzz target.
References
src/Core/Net/ElectrumClient.cstests/PalladiumWallet.Tests/Net/ElectrumClientTests.cs- Related: 0009, 0034