On Fri, 6 Dec 2019 at 04:40, Kenneth Porter shiva@sewingwitch.com wrote:
Thanks for the heads up
This affects all VPNs and is a consequence of using "loose" reverse path filtering for anti-spoofing. The default CentOS setting is strict filtering but you may have changed this to loose for some unusual routing situations. Check that the value of /proc/sys/net/ipv4/conf/all/rp_filter is still set to 1. If it's set to 2 (loose filtering), you're vulnerable.
So for ipv4 CentOS 7 and 8 may not be vulnerable out of the door (they set to 1 versus 0 which the announcement says is kernel default and sfe). However, they found ipv6 works without rp_filter so this is a problem. But guess what it gets worse .. every Unix and semi Unix OS seem vulnerable.. from the email:
We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android which allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel.
Now if 2 is needed for anything like docker/containers/etc then people are going to be royally screwed.
Technical details:
https://seclists.org/oss-sec/2019/q4/122
According to the report, systemd changed the default to 2 in November 2018 so many distros are vulnerable.
Here's Red Hat's explanation of why you might want to use a value of 2. "When RHEL has multiple IPs configured, only one is reachable from a remote network. Or why does RHEL ignore packets when the route for outbound traffic differs from the route of incoming traffic?"
https://access.redhat.com/solutions/53031
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos