Tailscale bug allowed a person to share nodes from other tailnets without auth
tailscale.com
tailscale.com
Deploying a prod fix within 24 hours is pretty great, they’ve been super cooperative and pleasant to deal with and (as far as I could ascertain) there was no apparent way to get the database IDs for nodes you didn’t have pre-knowledge of
I specifically appreciate:
- There's a specific date when the regression was introduced
- There's an end-date when the regression was fixed
- There was a thorough and conclusive analysis that was done that proves no exploitation occurred>A malicious individual who knew a target node’s database ID could generate and accept a sharing invite for that node without being an admin of the target node’s tailnet...as long as the individual knew the target’s node ID.
...
>The node ID is an integer used in the admin panel’s database, and is not related to the node "StableID" that is visible to Tailscale clients... IDs are not sequential or otherwise easily guessable.
I guess it depends on the search space of the IDs. If they're 64-bit integers, very hard to guess a valid ID. If they're only 32-bit integers, then you could have guessed, but it would be pretty obvious in Tailscale's logs.
In a prod deployment who has the rights to see this info without raising too many flags?
Anyone with automated deployments and self provisioning should be fine with that risk. I thought it was a lot more premature than this.
You can email me at tom@ (tailscale dot com)
https://github.com/tailscale/tailscale/security/advisories/G...
>A vulnerability in the Tailscale Windows client [...] Reviewing all logs confirms this vulnerability was not triggered or exploited.
Here too we have:
>This vulnerability was not triggered or exploited. Analysis of tailnet logs shows that [...]
Why on Earth would I want to use a security product that phones home... Regular WireGuard works perfectly fine for me.
I share your opinion, I don't want my security products to phone home, but the question was answered earlier : 'you' want a product that phones home so that the central data collection group can make statements like "vulnerability was not triggered or exploited." -- otherwise the onus is on the data holder to make similar assessments.
in other words , the proprietors of wireguard cannot make statements regarding their entire userbase. (This may or may not be a good thing.)
https://lists.zx2c4.com/pipermail/wireguard/2022-September/0...
> But right now? Is there something pending?
that ship sailed a long time ago in enterprise networking. Almost all major vendors now have Cloud Control, and all of them phone home for various things
Cisco, Aruba, Juniper, etc. All of them
- your ISP IP change all the time
- You need to open port
- You need to forward port to something else where the IP does not change ( wireguard server)
- You need to setup wireguard
- You need to manage auth / authz
Lot of things can go wrong and it's a lot of things to setup / maintain properly.
>- your ISP IP change all the time
I have a static v6 IP on the WG server (home router, running OPNsense).
Even if I did have a changing IP, I have a programmable DNS server that points to the WG server's IP.
>- You need to open port
One time setup on the server.
>- You need to setup wireguard
Installed just like any other distro package, plus one-time setup to generate the key and import it and the server's public key into systemd-networkd / NetworkManager.
>- You need to manage auth / authz
You generate a key on each device and register the public key with the server. There's literally nothing else to it.
>Lot of things can go wrong and it's a lot of things to setup / maintain properly.
I set it up about two years ago and it's been working unchanged since.
I believe that WG resolves the domain only once, upon config load. Not much help if the server IP changes after starting the WG client. Up to the user to realise and stop/start- not so convenient for eg embedded WG clients in travel routers
Wireguard does not handle this transparently.
Excuse my snark, but not everyone has a static v6 IP. I don't.
>One time setup on the server
Unless you happen to be behind a CGNAT or you're on a mobile network or or or or...
>Installed just like any other distro package, plus one-time setup to generate the key and import it and the server's public key into systemd-networkd / NetworkManager.
And if that won't work you're gonna be stuck debugging the network setup. I certainly do always end up debugging the VPN network stack eventually.
>You generate a key on each device and register the public key with the server. There's literally nothing else to it.
This won't scale to more than like 5 devices without being a major work item if a key was compromised or needs to be rotated (what if it turns out the RNG device was bad on your kernel at the time? Happened to SSH Keys on RPi's).
>I set it up about two years ago and it's been working unchanged since.
Not everyone is that lucky.
My ISP doesn't have it either. (They've been promising it for 2 years but keep delaying working on it.) I have an HE tunnel.
Also you ignored the sentence after that, which I had written to hopefully preempt this response.
>Unless you happen to be behind a CGNAT or you're on a mobile network or or or or...
Your server needs to have a globally reachable IP, yes.
>This won't scale to more than like 5 devices without being a major work item if a key was compromised or needs to be rotated (what if it turns out the RNG device was bad on your kernel at the time? Happened to SSH Keys on RPi's).
Depends on which key, of course. If a device's key needs to be rotated, you only touch that device and the server. If you rotate the server's key, then yes you touch every device.
>And if that won't work you're gonna be stuck debugging the network setup.
>if a key was compromised or needs to be rotated
>Not everyone is that lucky.
Sure. I know these things that happen never or rarely (currently, never), so I'm okay with doing them manually when they happen instead of outsourcing. I don't make decisions for other people or claim that what I do is best for other people. You should make decisions for yourself by evaluating the pros and cons for yourself.
And if they're not reliable, VPS providers are much easier to switch than "Tailscale".
Though, thinking about it, it's a privileged software running on every node in the virtual network, that is controllable from outside (cloud). So yeah, it needs to be way more trustworthy than some static wireguard setup you setup on a VPS.
Then you should continue using regular WireGuard. However, modern industry is plagued by an endless war with vulnerabilities, exploits, and malicious insiders. Even with adequate staffing, it's like a dam you're constantly patching to prevent leakage. We have to log everything, often offsite, and often into immutable storage. When the dam does eventually leak, we have to know how much and how it started. The logging is a feature to me.
Tailscale is building a service that doesn't require me to run and maintain a centrally connectable server, one that ties into a single-sign-on solution, one that logs activity, one that's introduced a system in which I don't even have to trust their control plane exclusively (Tailnet Lock). Just the seemless integration with Azure AD has saved maintenance time over NPS+Radius+ADConnect+OpenVPN.
Wireguard is great, I'm using it for all my site-to-site still (and it blows OpenVPN out of the water). But Tailscale has replaced all my client vpns for good reason.
Logging is a feature. Logging to some random 3rd party is not. Sure, if the 3rd party provides the service itself they need the logs to make it better but if stuff stays within your own infrastructure it should not phone home. And VPN service for enterprise certainly shouldn't have controller hosted on outside of company's own infrastructure
I think maybe you ran into a UI bug where it wouldn't work unless a subnet definition ended in a 0 (ie defining 192.168.0.1/32 would cause it to silently not boot up).
I also would like to be able to use my home lan DNS server for home lan hosts. It might not be a Nebula problem, but to do this I need to use DNS-over-tls in Android, through the Nebula tunnel.
Edit: noticed you were referencing the WIREGUARD phone app. I'll go try harder.
Same as outsourcing security: When you want a team of professional security engineers take care of it. (In that case, you may want to wish they are ethical, not overworked and actually care about your servers…)
Same as outsourcing security: When shit hits the fan, you have somebody else to point your finger at. No inconvenient questions to ask withing your org, potentially having to blame someone you like on a personal level etc.
Worst case, you have to ask the guy who green-lit the outsourcing some inconvenient questions, but if the company you outsourced to is big enough, you can easily take the "nobody ever got fired for buying IBM" escape route.
Also, I'm pretty sure you'll find detailed discussion of why people use Tailscale when there are options like vanilla Wireguard and OpenVPN if you google it or check their homepage. It fits many peoples' usecases.
After you're done being shocked, maybe you should read my comment more carefully. I didn't say "Tailscale shouldn't have logging". I didn't even ask "Why does Tailscale have logging?" I asked "Why would I want to use a security product that phones home?"
I don't make decisions for Tailscale. If they want to have logging, analytics or free puppies, they're welcome to. I make decisions for myself, and I've decided that I wouldn't use any security product that phones home.
For all the reasons I listed, then. If you can operate more manual, less user-friendly, and difficult-to-troubleshoot software, then by all means.
YUP
We recently deployed Tailscale in our organisation; I had looked at Wireguard very closely but decided that the ease of use of Tailscale meant we could get up and running much more quickly and easily and at relatively low cost (small team).
We'll re-evaluate as we move forward & probably need to deploy it to more users, but it was the difference between a few minutes setup to get all users into it versus several hours of figuring out the ins and outs of Wireguard & then getting the team onboarded.
While any security incident is frustrating, they are inevitable, and the only way to really judge an organisation is by its response. Tailscale's response here gives me more confidence, not less.
We are probably going to be looking at a redo of our whole auth at some point in the next 6-12 months as we plan to grow in size & move a lot more people into Tailscale.
The Nebula equivalent of this would be the Defined Networking folks, who do run a control server more akin to Tailscale. They say they are moving slow to focus on security, and I haven't heard of vulnerabilities like Tailscale, but also I think Defined Networks is much, much smaller in terms of users, so it may be a time will tell situation.
They both seem to have pretty smart folks.
Edit: For the record, I think Tailscale (as a company) builds excellent software and I like the idea of them making money and staying alive to keep doing the great work they do. I personally feel uneasy about using their proprietary control server in my own (home, etc.) networks, but I honestly wouldn’t even think twice about it if I was making that decision on behalf of a company.
On the other hand, they certainly have on a few ocassions gone out of their way to help Headscale, like documentation the changes to the V2 control server protocol, and even putting some relevant code in the open source repo to make it easier for Headscale.
Plus they try to keep backwards compatible with older control servers in the client, and trying not to break headscale is something that has been mentioned a few times in pull requests reviews.
....I don't see the connection between their change in ToS to mandate arbitration & the bug itself. There's no direct equivalency between the two.
On a personal note, I'm more neutral on arbitrations as a concept: They help facilitate faster legal resolutions in an environment where the time & cost overhead is purely human-derived. It often takes months, if not years, to form an impartial jury, a judge that's available to review the case, and for all relevant evidence to enter under the case's purview.
Also, the website that was cited in your previous comment doesn't provide any justifications for the claims made in their list. It simply states 10 reasons with no expansion into details/reasoning on the last 9 reasons. The first reason alone gives a tautologically-derived justification to its statement.
https://news.ycombinator.com/item?id=34358004
https://fairarbitrationnow.org/ten-reasons-why-arbitration-s...
Archive link: https://web.archive.org/web/20230117064553/https://fairarbit...
As noted in other comments [0], part of the reason why people use Tailscale instead of just wireguard or headscale is that they think they they have a throat to choke. The arbitration clause has the potential to make things more difficult in that regard.
> They help facilitate faster legal resolutions
Faster is not always better.
> [0] https://news.ycombinator.com/item?id=34421555
Cited comment chain:
>>> This seems pretty bad. I was pretty leery of Tailscale having too much control over my network when I tested it out and now seeing this security notification reinforces my decision to use vanilla WireGuard and Nebula for my home and datacenter use cases.
>> People mostly seem to pay for these products so that they can blame a third party if things go wrong.
> Ding, ding, ding! A lot of security/compliance folks like to pay money for scapegoats. It certainly helps with job security. Worst case scenario? Find another vendor.
-------
The Oracle/Dropbox model of 'here's someone to blame, just pay us for that' is a reasonable business strategy in an environment where the business in question wants as little involvement in the development of a product/service that they rely on: They just want the features that are being advertised, and are willing to pay for its siloed-off development. The actual proceedings of the potential arbitration in the future don't matter as much as the name on the sheet that they can rely on for blame/support.
-------
-------
>> They help facilitate faster legal resolutions
> Faster is not always better.
-------
Faster legal resolutions are better when the alternative is having to wait for months/years on a judgement.
The only scenario wherein arbitration loses out is in a constructed system where:
1) There are always impartial juries with the relevant subject matter knowledge to draw from for a given case
2) There are enough judges that there are effectively no wait times between being assigned a judge & getting a legal case resolved
In such a scenario, the bottleneck would exist in the discovery phase of the legal case, which can be resolved by mandating ALL conversations & interactions between the two entities be immediately submitted within a given time limit, whether directly, indirectly, or as part of a larger group.
Yup, that's why I'm a paying customer of Tailscale (biz tier).
Granted, you cant enumerate the ids, but neglecting permissions when adding a node seems like a really stupid oversight.
May I suggest that Tailscale spend some time to double-check that they are applying access control where applicable throughout all aspects of the application.
I appreciate the feedback on this vulnerability, and will continue to be a happy user - but please check that these oversights dont exist elsewhere.
If anything, this kind of response builds my confidence and trust in them.
They are targeting 6 OSes plus web, each of which has unique ways to get security wrong. On its own, that's one hell of an attack surface and I'd say the rate of vulnerabilities reflects that.
However, I'd say their security _posture_ is pretty good - from what I've seen, reported issues are typically patched within 48h of initial report (most companies ask for a 90 day window before bug reporters go public with issues, and often let it pass without fixing the issue).
They've had many flaws become widely publicized because they have great writeups of the issue, but I think I've only seen one critical-severity issue - most are low-impact. EG in this case you need to make requests until you guess an int64 correctly - which on average would 'only' take a year if you could somehow make ten trillion requests per second without being detected.
The clients for Windows, iOS and macOS are closed-source.
As a general rule, a closed-source server is bad, but ultimately it's somewhat tolerable. A closed-source client for a product or service that appears to have an acknowledged security posture is full-on unacceptable. I can't fanthom why they would shoot themselves in the foot like this.
> Is Tailscale open source?
> Mostly. Tailscale daemon client code is open source. Where the operating system is open source, the daemon and GUI are open source, and where the operating system is closed, the daemon is open source and the GUI is closed source.
You can run just the tailscaled daemons on Windows, it just wouldn't have a GUI, and that's fully open source[1].
Some more justification from Brad himself. [2]
[0] https://tailscale.com/opensource/#:~:text=Is%20Tailscale%20o....
This is one of those things you really want to fix. Relying on an ID value being hard to guess as a security measure can be easily become one of those completely-invisible-but-critically-load-bearing (in)security properties that is too easy to invalidate with new pushes/features/etc.
If these IDs were able to be exfiltrated or leaked or probed, it could have been disastrous. Really fortunate that this was caught now and wasn't in the wild for another year or two.
1. https://github.com/nccgroup/singularity/wiki/Preventing-DNS-...
This is a security product, and zero days in the code should be taken more seriously. Perhaps make the product all paid, and use the money to hire people to audit the code?
I don't know how much more seriously it could have been taken considering it was resolved within 24 hours of being reported.