Technical write up by the security researcher at <a href="https://emily.id.au/tailscale" rel="nofollow">https://emily.id.au/tailscale</a><p>ps. she's looking an employer rn // hire her!
> In theory, there is no path for a malicious Tailscale control plane to remotely execute code on your machine, unless you happen to run network services that are designed to allow it, like an SSH server with Tailscale-backed authentication.<p>Now I feel less crazy for not using Tailscale SSH for similar reasons.<p>I'd like to see a security evaluation of Tailscale, on a per feature basis.<p>I'd like to see tailscaled run with far fewer privileges.<p>Is there a Tailscale alternative that just does Wireguard + NAT traversal and doesn't try to do key management?
Do they have enough logs to reach out to people that were affected? As far as vulnerabilities go, this set is one is one of the worst ones I've seen this decade, and they seem rather straightforward.<p>Would be nice to get a blog post from them that goes a bit into impact, not just a report that tells you to update. It's nice that they responded quickly, but I feel like this shouldn't have happened in the first place for a network security company and it makes the Windows client feel like a bit of an afterthought. Looks like they have a PR open to switch it to named pipes, I hope that is properly reviewed by someone that knows Windows APIs before it's merged.
Super interesting article, and TIL Firefox does not implement PNA (Private Network Access).<p>Does anyone know why? It seems like an obviously good thing to have.<p><a href="https://wicg.github.io/private-network-access/" rel="nofollow">https://wicg.github.io/private-network-access/</a>
> If you run non-HTTPS web services on your Tailnet, and those services are unauthenticated or rely on Tailscale for authentication, implement an allowlist of expected HTTP Host headers to prevent malicious Javascript from accessing these services.<p>In my opinion, this should be done not only for non-HTTPS services, but for all services: the "default" virtual host (used where there is no Host header, or when it has an unexpected value) should have nothing except a static 4xx error page. This not only avoids DNS rebinding attacks, but also avoids automated attacks in which the attacker doesn't know the correct hostname for the service (mostly automated scans for vulnerable PHP scripts and similar).
I don't see a writeup of how this was fixed. Merely checking the Host header is insufficient -- the vulnerability would still be wide open to anyone who can open TCP sockets to localhost.<p>Windows has APIs (named pipes, DCOM (eww) and such) that allow authenticated local access to services. Unixes have unix sockets.
The concept of DNS rebinding and DNS records pointing to a private/localhost IP address is particularly interesting and I remember when I first came across it in the wild. It's not exactly re-binding in the classic attack sense described in the article: some US sportsbooks make you download a geolocation service that verifies your location in order to place bets. The sportsbook's front end communicates with it through a DNS record pointing back to 127.0.0.1, and opens up a WebSocket to talk to the service. I imagine the WebSocket is used to bypass the same-origin policy but perhaps someone more knowledgeable can speak to that.
The client app is not indicating that 1.32.3 for Windows is available yet but the download link on the site has been updated.<p>Tailscale client downloads are extremely slow at the moment, so I suggest you distribute one copy manually around your tailnet rather than bogging down their servers even more.
I've read the description several times and find it hard to follow:<p>..an attacker-controlled website visited by the node..rebinds DNS for the peer API to an attacker-controlled DNS server making peer API requests in the client,
including accessing the node’s Tailscale environment variables
I enjoyed the explanation very much. Even though I don't use mesh VPNs (yet), the architectural discussion of the vulnerability entailed numerous useful bits of background on browser and network infrastructure. Commendable work!
i might be mistaken but i think there was something else weird about the windows loopback interface. i can't remember what it was, but something like binding the loopback interface would bind on all interfaces by default maybe?
> The speed and quality of Tailscale's response to our report is unlike any vendor interaction I have experienced, and suggests a deep commitment to keeping their customers safe.<p>I have mixed feelings here as a Tailscale customer.<p>Yes a quick response is great, but this actual security issue is <i>pretty terrible</i> IMHO.<p>Anything other than an immediate response would have been akin to lighting their company on fire and walking away.
> We can ask Tailscale to open a path on an SMB share. Windows being Windows, it will send your username (and a hash of your login password) to this server, unprompted, despite having no reason to consider the server trustworthy.<p>Wow, I used to think Linux security was miles ahead of Windows security <i>more than 20 years ago</i> because of insanity like this. Fast forward 20 years. NTLMv2 is common, so cracking a password actually requires guessing the entire password instead of just 8 characters. But password guesses are much cheaper, so we haven’t gained much.<p>Microsoft, how long will it take you to fix this <i>for real</i>? Opening a URL or UNC path should not, without an opt-in, authenticate at all. If configured to authenticate, it should prove, zero-knowledge, to the server that the supplied password (e.g. the logged-in user password) matches the server’s expected password. No further information should be leaked.
I'm not sure I've ever seen a detailed technical writeup of a vulnerability before that started with such clear and concise instructions on the exact steps needed to defend against it at the start of the article before. In particular, making clear the priority of what to patch is excellent. If I'm a user of a product where a bug was found, I'm definitely interested in learning about what the bug was, how it was discovered, and whether I should be worried about other bugs in the future, but the absolute first thing I want is to do whatever I can to make sure I'm not affected by it. Listing what to patch and/or change in code might be more "boring" than the narrative of how the bug was found, and it might spoil the surprise, but I think sometimes we focus so much on the fun of the process of finding the bugs or revel in the cleverness of an attack (and those things are fun!) that we forget that the real point to it is to make our stuff safer. There's plenty of time for fun, but make sure you patch things first!
Releasing a patch and a detailed write-up on the same day seems like a bit of an unfortunate choice, especially for a WTF!! vulnerability like this. In software that doesn't auto-update, no less...
> If you visit my website, I am granted the honour and the privilege of executing arbitrary Javascript on your computer.
>
> This is a pretty bad idea<p>This is why I disable javascript by default, but I suspect that on this page it's needed to fix the theme or something, because the text is light grey on a white background, and all monospace sections are completely illegible.<p>Edit: I don't mean to hate on the author, the content of the article is really interesting!