SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Quote:
When apps run on Linux there's a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
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.
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:
Quote:
The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121...
So if I configure option 121 I can hack myself .
Last edited by business_kid; 05-07-2024 at 11:03 AM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
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.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
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.
Option 121 simply adds a static route on the client. It's unclear to me how this defeats a VPN.
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.
These routes are more specific than the "default route" used by the VPN, so they will "intercept" network traffic bypassing the VPN.
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.
Quote:
Originally Posted by ctrlaltca
Still, this seems like a lame attack to me, but quite feasible on public WIFIs like hotels and airports.
The lame part would be that there apparently exists VPN solutions against which this attack actually works.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.