frp: Unauthenticated Remote Denial of Service in the frp SSH Tunnel Gateway via Integer Overflow

Summary

An integer-overflow vulnerability in the frp server's optional SSH Tunnel Gateway lets any unauthenticated remote attacker crash the entire frps process with a single five-byte message. When the gateway parses an SSH exec channel request in pkg/ssh/server.go, it adds a small constant to a four-byte length value taken directly from the request. Because that length is fully attacker-controlled, a value of 0xFFFFFFFF makes the addition wrap around to a tiny number, defeating the only bounds check and forcing an out-of-range slice. Go raises a panic that nothing recovers, so the whole server exits. In the default gateway mode SSH clients are not authenticated and the request is handled before any frp token is checked, so the crash is reachable pre-authentication. It carries no state and is trivially repeatable, turning one crash into a sustained outage that drops every tunnel for every user.

Details

The exec request payload is a four-byte big-endian length followed by that many command bytes, and the length field is fully attacker-controlled. The gateway computes the end of the command as 4 + length. The constant 4 takes the uint32 type of the length field, so 4 + 0xFFFFFFFF wraps modulo 2^32 to 3. The only guard compares the real payload size against this wrapped value, so a five-byte payload passes the test 5 < 3, and the slice runs from index 4 to index 3:

// pkg/ssh/server.go:315-319
end := 4 + binary.BigEndian.Uint32(req.Payload[:4])  // 4 + 0xFFFFFFFF wraps to 3
if len(req.Payload) < int(end) {                     // 5 < 3 is false, so it passes
    continue
}
extraPayload := string(req.Payload[4:end])           // payload[4:3] -> panic

The handler runs in a bare goroutine and no function in the call chain installs a recover, so the panic unwinds to the top of the goroutine and terminates the whole process rather than the single connection:

// pkg/ssh/server.go:226
go s.handleNewChannel(newChannel, extraPayloadCh)    // no recover anywhere in the chain

The sink is reachable without credentials in the default configuration. When no authorized-keys file is set, the gateway disables SSH client authentication, which is the default and documented mode where users authenticate through the frp token embedded in the SSH command. The exec request is processed during the channel phase, before that token is validated, so an unauthenticated peer reaches the sink:

// pkg/ssh/gateway.go:74
sshConfig.NoClientAuth = cfg.AuthorizedKeysFile == ""  // default: no client auth