CVE-2016-5696 - "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous"

[Patrick Schleizer]

"Off-Path TCP Exploits: Global Rate Limit Considered Dangerous"

"In a nutshell, the vulnerability allows a blind
off-path attacker to infer if any two arbitrary hosts on
the Internet are communicating using a TCP connection.
Further, if the connection is present, such an off-path at-
tacker can also infer the TCP sequence numbers in use,
from both sides of the connection; this in turn allows
the attacker to cause connection termination and perform
data injection attacks. We illustrate how the attack can
be leveraged to disrupt or degrade the privacy guarantees
of an anonymity network such as Tor, and perform web
connection hijacking. Through extensive experiments,
we show that the attack is fast and reliable. On average,
it takes about 40 to 60 seconds to finish and the success
rate is 88% to 97%."

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?

Should a Qubes security upgrade apply this workaround?

Cheers,
Patrick

[Ilpo Järvinen]

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.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm not sure if I understand it fully, but isn't it required for the
attacker to reach both end of the connection directly? On Qubes, every
VM (besides sys-net) is behind NAT, so this isn't possible.

Also, IIUC, the worst what can happen is off-path attacker performing
some attacks normally requiring being in-path. Something that using
properly encrypted/authenticated protocols guard against already.
Otherwise using any public wifi (which is much more common case than
this attack) could be fatal.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXr4jAAAoJENuP0xzK19csc98H/ReSlwHnrZ+i+geia+LNj/X1
QgKgHJqIyiEkgoPrKOiiH7N/IisC8IpylYddiuKJ0HYoFKlQmk7yDeGT4B4HAdrr
HtGlQC+wg5GRINvxOnhKjhJsRByEYgOZuMESVaZUbI0SMQhR2nUN6tj559EDkJRH
uqUpX8m9qZN/qoQ+lhoPOpOWuWl8z0o7UyhdhcGs9l0+1+khKKMxw50qvg6z5W8l
CSuV9kJp+ivySIjMscscFeb6If5+oH83UuoqbmIdJ0755SmIzTrK+iCOn/rn04Ak
STx5knA71s0KGnmRaMtCtaUltEGG03wVSAEZjrWCMfJWMP6MxfftxOr+zsaSIfM=
=CCU0
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Ilpo Järvinen:

I agree, should we decide to deploy this workaround, it would not hurt
to apply it everywhere. (Also to cover non-standard cases of people not
using sys-net or so.)

Cheers,
Patrick

[Patrick Schleizer]

CVE-2016-5696 and its effects on Tor

https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor.html