| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
 Posted: Wed May 08, 2024 4:58 am Post subject: dhcpcd and tunnelvision (CVE-2024-3661) |
 |
|
The default configuration of dhcpcd.conf contains the line
| /etc/dhcpcd.conf wrote: | | option classless_static_routes |
My understanding is that this line makes the machine vulnerable to the tunnelvision attack from CVE-2024-3661.
So a simple workaround for the vulnerability appears to be to comment out this line. I did so and did not realize any difference in my home network. Since AFAIK android does not support this option as well but can connect in practically all networks, this option really seems to be unneeded.
My particular questions are:
- Does removing of the above line avoid the vulnerability completely?
- What problems are to be expected if this line is removed?
|
|
| Back to top |
|
 |
Banana
Veteran
Joined: 21 May 2004
Posts: 1413
Location: Germany
|
| Posted: Wed May 08, 2024 7:36 am Post subject: |
|
|
Hmm
https://www.leviathansecurity.com/blog/tunnelvision
| Quote: | Is TunnelVision a vulnerability?
This is debatable. We’re calling it a technique because TunnelVision doesn’t rely on violating any security properties of the underlying technologies. From our perspective, TunnelVision is how DHCP, routing tables, and VPNs are intended to work |
And some google translate (rough) from: https://www.heise.de/news/Tunnelvision-Angreifer-koennen-VPNs-aushebeln-und-Daten-umleiten-9710188.html
| Quote: | Linux has known so-called network namespaces since kernel 2.6.24 (born 2008). This allows the network to be partitioned in such a way that the tunnel vision attack no longer leads to the disclosure of unencrypted data traffic. However, a device isolated in this way cannot access resources on the LAN.
Otherwise, it may be possible to secure the VPN connection using classic firewall rules so that data packets running over the VPN are not thrown away. However, even this is not complete protection, according to the discoverers: With a statistical side channel attack, it is still possible to draw conclusions about the IP addresses that the victim is heading to. To do this, however, the attacker must be able to intercept the data traffic, for example in an unencrypted WLAN. |
_________________
My personal space
My delta-labs.org snippets do expire
PFL - Portage file list - find which package a file or command belongs to. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed May 08, 2024 8:03 pm Post subject: |
|
|
| Banana wrote: | Hmm
https://www.leviathansecurity.com/blog/tunnelvision
| Quote: | Is TunnelVision a vulnerability?
This is debatable. We’re calling it a technique because TunnelVision doesn’t rely on violating any security properties of the underlying technologies. From our perspective, TunnelVision is how DHCP, routing tables, and VPNs are intended to work |
And some google translate (rough) from: https://www.heise.de/news/Tunnelvision-Angreifer-koennen-VPNs-aushebeln-und-Daten-umleiten-9710188.html
| Quote: | Linux has known so-called network namespaces since kernel 2.6.24 (born 2008). This allows the network to be partitioned in such a way that the tunnel vision attack no longer leads to the disclosure of unencrypted data traffic. However, a device isolated in this way cannot access resources on the LAN.
Otherwise, it may be possible to secure the VPN connection using classic firewall rules so that data packets running over the VPN are not thrown away. However, even this is not complete protection, according to the discoverers: With a statistical side channel attack, it is still possible to draw conclusions about the IP addresses that the victim is heading to. To do this, however, the attacker must be able to intercept the data traffic, for example in an unencrypted WLAN. |
|
While I agree with both, it doesn't answer my questions:
Sure, you can use namespaces or firewall rules, but as mentioned this gives further restrictions. Things are much simpler if you can just disable the “feature” (option) which makes the attack possible.
dhcpcd seems to be flexible enough to allow for this. I am just not sure whether I understood it correctly that this really prevents the attack completely. And I would also like to understand the cost of disabling this feature/option. As mentioned, at a first glance, I see no cost at all, but I do not really understand what this option means. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
