101–110 of 238 posts
There is nothing novel in the attack nor it's a security problem. DHCP environment must be trusted. We do have IP Source Guard and DHCP Snooping for decades to avoid scenarios from that link ( and many other).
I'm more worried about people using VPN services that are IP4 only while having IP6 enabled in the system.
That can go terribly wrong...
Earlier quoted context omitted.
Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all. So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN conne…
Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord reall…
Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic.
You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.
This is a perfect example of the CVE mining. There is nothing novel in the attack nor it's a security problem. DHCP environment must be trusted. We do have IP Source Guard and DHCP Snooping for decades to avoid scenarios from that link ( and many other).
This is a great find and a real security bug. I cannot believe how many people are downplaying this work.
Earlier quoted context omitted.
I think a public wifi network effectively being able to disable someone's VPN is pretty bad.
if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.
Earlier quoted context omitted.
So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible. I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user. T…
The side channel attack is silly and impractical. You know it's silly. I know it's silly. Let's quit pretending. The firewall rule is 100% sufficient to defend against this exploit. All good VPNs already provide it by default. It's not deep. They're just routes. Please stop the FUD.
Earlier quoted context omitted.
Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord reall…
You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic. You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing tra…
Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up.
Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)
Earlier quoted context omitted.
The side channel attack is silly and impractical. You know it's silly. I know it's silly. Let's quit pretending. The firewall rule is 100% sufficient to defend against this exploit. All good VPNs already provide it by default. It's not deep. They're just routes. Please stop the FUD.
Side channels are a huge danger. An example is cryptographic functions have been cracked because of timing differences based on the key or data being encrypted. This is why cryptographic ciphers are implemented in constant time code (i.e. code that always runs in the same amount of time regardless of its input).
I imagine there is also probably some other prior art. But that's a very well known one.
They also claim that it affects all VPN clients in the headline, yet so many such clients setup firewall rules to block traffic to/from the physical interface as they acknowledge in the write-up. Most of the VPNs that are claiming to hide your identity or where such cloaking is important tend to implement that. I'm sure plenty of setups don't have it enabled by default, but I think it would have been productive to document what percentage of leading personal/commercial and corporate VPN solutions have this enabled by default.
A good write-up and explanation for the lay person, but I think the headline over-sells it a little bit given the number of clients that would prevent most of the data leak with those firewall rules and not acknowledging the prior art in this area.