On Sat, 13 Aug 2016, Patrick Schleizer wrote: > "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" > > https://regmedia.co.uk/2016/08/10/sec16_tcp_pure_offpath.pdf > > https://security-tracker.debian.org/tracker/CVE-2016-5696 > > ##### > > Said to be fixed in linux 4.7, which is not yet available from any > package sources. > > The often quoted workaround for now: > > /etc/sysctl.conf > net.ipv4.tcp_challenge_ack_limit = 999999999 > sysctl -p > > So it would also suffice if that fix was applied in sys-net?
Why do you think that sys-net in particular need this workaround? Normally it is not an endpoint for any TCP connections? The workaround helps (and the attack works) only if it's applied to the kernel which terminates the attacked TCP connection. I don't think that it is such clear cut that sys-net is enough, although attacking TCP connections that are terminated behind NAT is somewhat more difficult. The attacker needs to have a legimite connection to the VM behind NAT for challenge ack counting purposes. To have such connection, the attacker would need to trick the user to initiate a TCP connection to a host under his control from the same VM as the attacked connection (Fig 2 case from the paper). Whether that is realizable for the off-path attacker depends on TCP usage patterns of a VM. > Should a Qubes security upgrade apply this workaround? -- i.
