There's some exploit that's been out there a long time but only noticed recently - Er, This one which uses option 121 on dhcp clients. Now I gather it's difficult In the case of Slackware's chosen dhcp servers, how vulnerable are Slackware users? It's not like I'm in the Secret Service, I'm just curious.

Option 121 simply adds a static route on the client. It's unclear to me how this defeats a VPN.

If your system is configured as a DHCP client, you are by default accepting route information from an untrusted party. Any other user on the network could quite easily take over the DHCP Server role, with or without the use of option 121.

No expert here, but It doesn't work on Android because Android DHCP client(s) don't support option 121. So that's the key. That's why I asked if Slackware DHCP clients support option 121. What's more important, I suppose, is if they can be compiled without option 121 without hurting anyone. If anyone listened in on my traffic, they'd quickly get bored.

EDIT: From the Article: So if I configure option 121 I can hack myself .

I am not an expert but if one does not use VPN splitting app or uses app that blocks non-vpn traffic (e.g. Mulvard) then vpn connection is not vulnerable to this attack.

If I understnd right the only one who can bypass vpn using DHCP options 121 is the admin of DHCP server.
So if your are not the admin of DHCP server that means you cannot set or change DHCP options, including Option 121.
But if you are in Corporate/Enterprise Network or Shared or Public Networks then lots of things might happen...

There is a link in post#1 which is easily missed. What perked my interest was that Android alone was immune - there's no option 121. iOS presumably is vulnerable, as is linux. The video showed lease renewal time as the vulnerable point, which happens automagically. A dhcp client's query for a lease is answered by the hacker.

That sort of stuff is above my pay grade, hence the question. I wouldn't have asked if I knew. But security of lease renewal is a grey area for me. The dhcp client is asking "Is there anyone out there?" and when it gets an answer, it doesn't reply "Who the hell are you?", it says "Thanks."

One aspect of this is, suppose I am a Slackware admin, and that I host some users. According to what I've read, I could configure DHCP on my host and spy on my users.

Not only android. OS in VM will not be vulnerable either.

Also, this is useful in hotel, airport, internet cafe, public wifi environment where rouge DHCP server set up is possible.
This way, while communication is still encrypted, connected sites are visible.

Non-corporate VPns are used to route all traffic through the VPN itself, so they create a default route (0.0.0.0/0) on their gateway, usually with a lower metric.
DHCP usually pushes to the client an IP address for the interface and a gateway IP address. It can also push additional routes, using eg. option 33 (RFC 2132, obsolete) or option 121 (RFC 3442), that the client "should" install and use.
This attack exploits these options by pushing to clients a lot of routes (eg. 1.0.0.0/8, 2.0.0.0/8, and so on) pointing them to a malicious gateway.
These routes are more specific than the "default route" used by the VPN, so they will "intercept" network traffic bypassing the VPN.

Still, this seems like a lame attack to me, but quite feasible on public WIFIs like hotels and airports.

Ah, so there's where the issue lies: The VPN relies on IP routing priorities when deciding whether or not to encrypt traffic instead of using a policy, probably by routing traffic through a virtual interface (most likely PPP).

That seems ridiculously short-sighted and should be considered a vulnerability in and of itself, or at the very least a high-severity bug. This is not the fault of the DHCP client correctly accepting DHCP option 121.

I would assume that all IPsec-based VPNs are immune to this, as they are policy-based.
The lame part would be that there apparently exists VPN solutions against which this attack actually works.

Of course you could.

For instance, you could exhaust the entire scope of the local DHCP server by flooding it with DHCP requests, making sure that any subsequent requests from other clients would be served exclusively by your malicious server.

Insecure networks are insecure.

1 members found this post helpful.

DHCP Snooping on Cisco switches can make the network to avoid using unexpected network ports for DHCP traffic, hence mitigating (to an extent) the issue. I'm certain this feature exists in other vendors. And I'm certain, as Ser_Olmy explained above, there are other ways to make this exploit to work - where there's a will, there's a way.

Option 121 exists at pretty much each and every DHCP server out there, and yes, aside of Android, all OSes are "vulnerable" by implementing things per the book, but if one can spin up a DHCP server in your network and get it unnoticed, you have much bigger problems than just a rogue DHCP server.

IDK VPN (at all). When I saw this yesterday, comments seemed to vary from: irrelevant clickbait -to- VPNs don't really work!
Here's the links: https://arstechnica.com/security/202...ntire-purpose/
https://news.ycombinator.com/item?id=40284111 https://news.ycombinator.com/item?id=40279632 (Origin: https://www.leviathansecurity.com/blog/tunnelvision )
And https://krebsonsecurity.com/2024/05/...-as-it-claims/

Even tho I'm clueless here, web-research seemed to say: 1/3 to 1/2 of internet users do use a VPN! (Totally surprising to me!)

The dhcp client could be confined to a dedicated network namespace. The default namespace can then be routed through this dedicated namespace through a pair of veth.

It might be a good idea to add this setup to rc.inet1 considering rc.inet1 has already supported a bunch of miscellaneous configurations.

1 members found this post helpful.

TLDR but I presume anyone on the Internet is connected through EVPN at some point.