Impact
When receiving a data packet from an unknown IP address/port combination, fastd will assume that one of its connected peers has moved to a new address (for example due to internet lines with dynamic IP, or roaming between WWAN and a local internet connection) and initiate a reconnect by sending a handshake packet. This "fast reconnect" avoids having to wait for a session timeout (up to ~90s) until a new connection is established.
Even a 1-byte UDP packet just containing the fastd packet type header can trigger a much larger handshake packet (~150 bytes of UDP payload). With fastd v22, this number is doubled, because two handshakes are sent (one in a pre-v22-compatible format and one in a new L2TP-style format). Including IPv4 and UDP headers, the resulting amplification factor is roughly 12-13.
By sending data packets with a spoofed source address to fastd instances reachable on the internet, this amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack.
fastd has always implemented rate limiting for handshakes to unknown IP addresses and ports to 1 handshake per 15s to avoid this kind of attack, however the rate is limited per-port and not per-address, thus still allowing handshakes to be sent to all 65535 UDP ports of the same IP address unlimited.
Patches
The issue has been mitigated in fastd v23 by a number of changes:
- Rate-limiting has been changed changed to be applied per-address instead of per-port
- Only one handshake instead of two handshakes is sent for fast-reconnect (by determining from the format of the data packet whether a pre-v22 or L2TP-style handshake should be used)
- Require at least a full method header instead of just a single byte for a data packet to be considered valid. This does not have an effect on instances that enable the
null method (regardless of null being actually in use), as a single-byte UDP packet is a valid null keepalive, but for all other methods the amplification factor is slightly reduced.
The following patches need to be backported to include the mitigations and related fixes in v22:
- ce1b79b12dbf handshake: pass initial handshake flags to fastd_protocol::handshake_init()
- 1f233bee76b7 receive: do not send both L2TP and compat handshakes for fast reconnect
- d03a0a17347e receive: require data packets to contain at least a full method header
- c1a07b3f2b90 log: add support for printing IP addresses without port using %I
- 9df7e5163784 receive: add missing static for internal function
- 5f63fcfc18ae receive: ignore port for backoff_unknown()
- 3940150e801d receive: unblock unknown handshakes after successful handshake from same address
Workarounds
Only fastd instances that allow connections from arbitrary IP addresses are vulnerable. Instances in a "client" role that configure their peers using the remote config option (which includes the common deployment as part of the Gluon wireless mesh firmware) will not respond to unexpected data packets with a handshake and are therefore unaffected.
Impact
When receiving a data packet from an unknown IP address/port combination, fastd will assume that one of its connected peers has moved to a new address (for example due to internet lines with dynamic IP, or roaming between WWAN and a local internet connection) and initiate a reconnect by sending a handshake packet. This "fast reconnect" avoids having to wait for a session timeout (up to ~90s) until a new connection is established.
Even a 1-byte UDP packet just containing the fastd packet type header can trigger a much larger handshake packet (~150 bytes of UDP payload). With fastd v22, this number is doubled, because two handshakes are sent (one in a pre-v22-compatible format and one in a new L2TP-style format). Including IPv4 and UDP headers, the resulting amplification factor is roughly 12-13.
By sending data packets with a spoofed source address to fastd instances reachable on the internet, this amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack.
fastd has always implemented rate limiting for handshakes to unknown IP addresses and ports to 1 handshake per 15s to avoid this kind of attack, however the rate is limited per-port and not per-address, thus still allowing handshakes to be sent to all 65535 UDP ports of the same IP address unlimited.
Patches
The issue has been mitigated in fastd v23 by a number of changes:
nullmethod (regardless ofnullbeing actually in use), as a single-byte UDP packet is a validnullkeepalive, but for all other methods the amplification factor is slightly reduced.The following patches need to be backported to include the mitigations and related fixes in v22:
Workarounds
Only fastd instances that allow connections from arbitrary IP addresses are vulnerable. Instances in a "client" role that configure their peers using the
remoteconfig option (which includes the common deployment as part of the Gluon wireless mesh firmware) will not respond to unexpected data packets with a handshake and are therefore unaffected.