Skip to content

[Security] TcpTransport logs a peer-supplied address unescaped, so a peer forges log records #1629

Description

@pathosDev

TcpTransport.onData names the peer on both of its WARN tiers:

rejecting malformed frame from ${connection.peer ?? '<unknown peer>'}: ${checked.problem}
wire handler threw on a frame from ${connection.peer ?? '<unknown peer>'}; closing

connection.peer is built from the peer's own hello payload, and isNodeAddressData requires only that systemName and host are non-empty strings — no character class, no length bound. A peer whose host contains a newline renders a log line containing a newline, and ConsoleLogger writes one line per record: the peer forges as many additional records as it likes, each indistinguishable from a genuine one. That is #573's shape, on the socket path.

Under mTLS certificateVouchesFor narrows it, since the claimed address must match the certificate. A plaintext cluster has no such check — the peer need only complete a handshake.

The MessageChannelTransport sibling already sanitises: it escapes LF, CRLF, CR, U+2028 and U+2029 and clips a long host. The same helper applied at the socket seam closes this.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: mediumUseful, not urgentsecuritySecurity-relevant — see severity label for impact tierseverity: mediumModerate impact or requires specific conditions

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions