Hacker News new | ask | show | jobs
by devmor 529 days ago
That is a whole lot of different levels of exploits that would have to be chained together that you just trivialized there.

How do you suppose they gained access to the kernel and userspace just by having a network connection to the laptop?

2 comments

By using an unpatched rce in any network exposed code. The whole point of firewall is to prevent bad hackers from the bad internet to exploit your unpatched rces, abuse your default passwords, host based security you shouldn't have had in the first place and access stuff using compromised credentials you didn't revoke or didn't know you should have revoked. Because consistently doing all of that all of the time is hard for creative professionals. It's a chore. It's a tax.
How exactly is Tailscale different to literally any other piece of network capable software in that regard?

NAT traversal requires careful coordination between two devices to create a connection, it’s not like any random device on the internet can perform NAT traversal against a machine just because it’s running Tailscale (not to mention every modern browser has NAT traversal built in for WebRTC connections).

And if the issue doesn’t arise from using NAT traversal, then how does Tailscale expose anything more significant than what a traditional VPN will expose? After all the only difference between a P2P VPN and a traditional VPN, is that a traditional VPN bounces all your traffic off a common server, rather than attempting P2P connections.

I think the point is not that there are necessarily exploits, but by compromising one node in the tailnet they now have the ability to hit code in these locations, or services running on your tun0 interface on your laptop etc.
How is compromising a a single node in a tailnet more dangerous than compromising a single node in a traditional VPN?

Traditional VPN don’t usually put firewalls between machines on the network, because traditionally the whole point of a VPN is to avoid the need for firewalls to provide security between nodes on the virtual network, by assuming that only safe machines can connect to the VPN.

You would typically remove the default any to any ACL rule, and allow the connections that you need. The compromised node normally would not have access to anything interesting. Normally it’s jailed, or would not be able to make outgoing connections.

Am I missing something?

The ACL logic happens in the tailscaled on the destination though doesn't it? So even if you block the access via the ACL the packet has still gone through the network stack and go runtime etc before the traffic is dropped which is a significantly bigger surface than a (traditional) external network firewall.
I see your point. You are talking about a vulnerability.

You are right. Tailscale nodes can send packets processed in any other node, irrespectively of ACLs. Essentially each node gets to “run code” in other nodes, which is normally dropped. I don’t know how deep the Tailscale packets go before being dropped (perhaps the coordination server distributes firewall rules).

But you have to compare with another access method, like, the hub and spoke VPN. The compromised and uncompromised nodes connect to a VPN access server. A compromised node sends packets that are processed in the VPN server, but can also connect to the uncompromised node, meaning, the latter has to process and drop the packets of the former. You have to trust the OS IP stack. To some extent, the same is true if the trusted node VPNs directly to the untrusted node. During an established connection, the networking stack of the trusted node has to block the other side.

Maybe someone familiar with the implementation of ACLs in Tailscale could chime in.

Update: The ACL rules are applied to the incoming packets over tailscale interface. The filtering is then done by tailscaled. The packet has gone past the interface and processes by tailscaled. So an unauthenticated packet indeed travels through the kernel space all the way to the userspace.

How is this any different to any other piece of network capable software that’s listening to a port on your machine?

An external network firewall can only offer protection if you can somehow guarantee that every packet that hits a specific node is first routed via that firewall. Traditionally nobody has setup networks like that, because it requires routing every single packet via a single common bottleneck, causing huge latency and throughput problems.

As for packets going via the network stack, and then the go runtime. Do you honestly believe there’s set of vulnerabilities out there which would allow random external packets to be sent to a random machine, and cause an RCE by virtue of simply being process by the OS kernel, which somehow can only be exploited if you’re running Tailscale? Better still, if such a vulnerability exists, what on earth makes you think your firewall isn’t also vulnerable to same issue, given that pretty much every firewall out there is built on the Linux kernel these days.

It goes into tailscaled before it's dropped, and tailscaled has had a number of security issues in the past (including RCE):

https://tailscale.com/security-bulletins#ts-2024-005 https://tailscale.com/security-bulletins#ts-2022-004

> Am I missing something?

Yes

> You would typically remove the default any to any ACL rule

This part doesn’t happen.

Defaults are rarely changed.