If it runs as your user and can only log in as you, then I wouldn't expect it to be able to become root. But if it can log you in as different users, I would expect that 1. it needs to run from root, and 2. it can log in as root.

We did Tailscale-like SSH reverse tunnels at scale first in 2013 and the main issue has always been that there are no good libraries. Bash scripting around the OpenSSH binaries is pretty much the only way to go.

There's Paramiko, but Python is still a huge liability in memory-constrained systems.

Making a useful multi-uid-capable daemon that can’t become root but is not so nerfed that no one uses it is nontrivial. If nothing else, what policy would you use? Why do you think that no other uid is equivalent to root?

> Spoiler alert: This applies to all software. This is why security preaches defense in depth.

Thank you Mr/Mrs Pedant.

However this is a VPN product I am talking about which has an integral part in the defence in depth of which you speak.

Therefore it is only right and proper that I, and others, should be able to trust them to a greater degree. Never 100% of course, as you say. But if you are selling me a security product then you should be able to demonstrate you have put some damn effort into securing it.

"insecure argument handling" in a security product is not a good look. It stinks of sloppy coding practices followed up by a lack of security auditing.

I haven't had problems with NetBird on Android and Linux. I have also used tailscale and found it comparable.

Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.

> Another concern I have is whether a compromise of Tailscale's own infra could let an attacker just add itself to my network. Apparently the "Tailnet Lock" feature mitigates this, but it is off by default.

Yeah, we use "tailnet lock" to sort of cover that. AFAIK its the only option available.

I say "sort of" because "tailnet lock" is a bit half-assed in its design and implementation.

For example, you cannot sign new nodes from mobile devices (e.g. iOS). And as we know, locking down iOS is easier than a full desktop machine. So that's a bit of a missed opportunity. And as usual, there's a Tailscale Github issue open for it for years ...

And in practice, the "tailnet lock" addition is done through the `tailscale` software on the desktop/laptop. Its click a button or run a CLI without further authentication/authorisation required. So basically anyone could do it. And the keys are, of course, open to exfiltration, you can't use a Yubikey or anything like that. And you can't require multi-signer. Complete joke really.

Also if you use "tailnet lock" with the Tailscale Mullvad integration, its a one-way street. You can sign Mullvad nodes so they can be used as exit nodes, but it is impossible to revoke signatures from obsolete/replaced Mullvad nodes (with tailscale clients, you simply delete them from the org which means they have to re-auth and re-join under a new ID ... but you can't do that with the Mullvad integration, so the 'ghost' exit node could easily return). Your only option is to remove the signing node that signed the Mullvad nodes and start again from scratch. Another joke.

So, yeah, "better than nothing" is the way I would summarise "tailscale lock".

> If I was an APT, compromising Tailscale would be priority number 1!

Crowdstrike would be at a much higher priority. They already have a cloud connected root console to all the machines in entire corporations. Compromising your network is small potatoes compared to that.

> Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22

Fair question. The short answer is my wording was a little off.

We do have pure SSH bastion hosts. Those are OpenBSD-based with a few tweaks, but basically they are locked-down and heavily monitored to within an inch of their life.

The reason Tailscale is there is mostly so the non-techies can access intranet portals and such-like.

But Tailscale does have a useful party-trick for the techies too, in that you can do DNS-suffix based routing (without needing to use Tailscale's DNS).

So they can automagically hop via a Tailscale bastion host to "*.$region.rds.amazonaws.com" or whatever. You just specify the DNS suffix and anything on that wildcard will work. It therefore enables us to further harden access to that stuff to a source IP of the Tailscale bastion hosts (in addition to the usual security stuff, of course).

Tailscale takes care of the automagic load-balancing/re-routing to the Tailscale bastion hosts, so we just have a bunch installed in random geographically-dispersed places and as long as >0 are up and running the Techies will always have a route to where they need to be.

Obviously the above is over-simplified summary before the pedants start picking it apart. ;)

> Tailscale contracts with cybersecurity firm Latacora to conduct

And these published audits of the `tailscale` software are where ?

Even half-serious VPN providers like Mullvad publish in public their regular security audits of their app and infrastructure.

There is zero reason Tailscale cannot do the same.

And frankly, given the nature of this vulnerability, "insecure argument handling" I'm not entirely sure it has been audited ? Or if it has, they should be looking for a new auditor ASAP !

> Did you try Headscale? https://github.com/juanfont/headscale or netbird?

Am aware of them but IIRC they are both unaudited which kind of brings us back to square one ? We would still end up running them at arms-length as we do with Tailscale at the moment.

Isn't Headscale server-side only ?

Also a bit strange that "Tailscale vs Netbird" doesn't feature more prominently on their "Compare Netbird" page. It is hidden behind "Load More". ;D

> I absolutely guarantee they undergo regular formal security audits. There's no question.

Well, they clearly don't if they have an "insecure argument handling" vulnerability.

As others here have said already here, its an "venerable and ancient class of bugs".

Its the sort of thing that should be picked up by modern defensive programming that includes fuzz testing.

And it is CERTAINLY the sort of thing that should be flagged by any competent security audit. "insecure argument handling" is bread-and-butter for security auditors.

> I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?

SOC2, ISO27001 and all that shit is not the same thing.

As I said, anyone serious who is proud of having had their software audited as clean would publish their reports in public. Nothing to hide. And it strengthens your case with customers.

It can always be a suitably redacted management summary written by the auditor. That's what everyone else does.

OTOH, if you run vanilla ssh on a publicly accessible machine where only port 22 is open, sshd only allows publickey-based authentication and the only accepted key types are FIDO2/U2F hardware-backed keys, it's probably more secure again (less attack surface).

With a plain VPN like WireGuard when they get access to your network, they don't have plain ssh, not to mention root ssh access to hosts. This is a serious issue.

I just don't use stranger's machines to access my personal stuff. Possibly compromised stranger's machines. I don't see the benefit about that, as I have more laptops than I need.

I do not understand this rebuttal.

I also run self-hosted Wireguard. Initially on a Debian box, nowadays it is integrated into my router (admittedly, this is closed source). For around 6 years at this point.

The whole thing could not be easier and simpler. It has never randomly broken on me. It is fast. It is free. There is no middle man, no vendor.

I never understood the popularity of Tailscale, though that is on me. I'm sure it is a great product, I just never tried it, do not seem the target audience.

What confuses me is the often accompanying, sometimes aggressive anti-selfhosting stance in these sorts of threads. I do not see this in other topics, e.g. someone mentioning they run Jellyfin isn't met with "why not Plex?". Where does that come from? We are on HackerNews, not ProductShillNews, aren't we? I guess self hosting Wireguard is too boring to warrant any further discussion? The VPN equivalent of a Toyota Corolla.

I also tested tailscale, headscale and netbird and found all these drain your battery on mobile.

Others report no issues but I had massive drain on iOS even with only 4 connections open.

Native wireguard is unnoticeable.

I found Netbird to be easier to implement. Among its peers it seems to be the most complete open source solution. It IS a bit fast moving though so there might be issues. And they just added an Agent network thing that nobody asked for but it's par for the course these days.

Because wireguard to tailscale is like git to git GUIs. It's solid base but never should be used separately without a proper wrapper if one wants to keep one's sanity.

If you don't care to invest half an hour into learning some basics of how computer networking and in particular CIDR notation and subnet masks work, maybe it is not for you.

Allow any (ip4) traffic to enter the tunnel, install a route in the default routing table to make that happen (well the second depends on the client)

Does it do the opposite of that?

Is this what your referring to? https://utcc.utoronto.ca/~cks/space/blog/linux/WireGuardAllo...

[dead]

The issue here is there is NO single system API for looking up user account entries on Linux.

It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go.

Then, "link to libc". Which libc? glibc? musl?

Why is that worse than the issue itself? If someone could figure out, say, my root password via an ssh timing attack, that seems bad. Sending 100 packets for each keystroke to protect against this seems cheap in the face of that.

The example doesn't seem worse, but more importantly - are these issues part of the class (and why)?

1.98.9 has already been tagged since bulletin was published (don't know why they chose on github to tag but not release).

1.98.9 version exists! That's not the question. It should already have been made available for Linux distros assuming this resource from Tailscale is accurate https://pkgs.tailscale.com/stable/?v=1.98.9

Edit: Their changelog also mentions the version: https://tailscale.com/changelog#all

Good point. I self host headscale but it also has the ssh feature, probably also insecure.

And sometimes it’s just impossible to get a CVE number in a reasonable amount of time, or indeed at all.

To be clear creating your own custom IDs isn't the same thing as being a CNA, but some of the motivations are the same.

If it used one of the standard system APIs for looking up user accounts (e.g. getpwnam(3)), there's no way it can happen.

This is incredibly bad engineering, on level of a SQL injection, in 21st century. Something a highschool student experimenting with scripting could come up with, but not a supposedly professional software company.

They actually do use "os/user".Lookup() as a fallback if fetching via getent(1) fails, so they might be using NSS modules to dynamically define users and then not linking their binaries with glibc (musl and the opt-in pure-Go implementation of "os/user".Lookup() do not support NSS).

Still, requesting the information from systemd-userdb would be a better way of doing this if it's really necessary.

EDIT: Yeah, some older comments confirm that was their reasoning. https://github.com/tailscale/tailscale/commit/1fc1077052dfa7...

that's stupid. getent passwd will fetch the user list from the network depending on setup. Have fun fetching 40000 records from the network every call

Are there any actual systems that can run Tailscale and that have faulty getent?

A correct implementation would be to just call glibc directly, this seems like a hasty fix to get the patch out the door. The history of vulns from bad shell escaping is as old as bash, whenever possible you probably shouldn't be mixing code and data, especially in a security critical application like this.

This is just a dirty fix. It adds weird restrictions and masks issues.

Refactoring external invocations to use safe argument handling is a better way to fix it. Along with tests that exercise weird names.