Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

tailscale.com

Post reply on HN
Print view View original

101–110 of 157 posts

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#101

Post by Retr0id »

traceroute66 wrote: post #87

At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…

I've been planning a similarly "paranoid" (but apparently not that paranoid) Tailscale setup, for the same reasons.

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. If I was an APT, compromising Tailscale would be priority number 1!

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#102

Post by Retr0id »

wereHamster wrote: post #40
kbumsik wrote: post #5

Why own numbering instead of CVE?

Some reasons why an org might want to become their own CNA: https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/

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.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#103

Post by traceroute66 »

Retr0id wrote: post #101
traceroute66 wrote: post #87

At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…

I've been planning a similarly "paranoid" (but apparently not that paranoid) Tailscale setup, for the same reasons. 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 . If I was an APT, compromising Tailscale would be priority number 1!

> 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".

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#104

Post by traceroute66 »

_joel wrote: post #98
traceroute66 wrote: post #92

Earlier quoted context omitted.

> 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…

Agree, but I'd class Mullvad as the most serious VPN provider, personally.

> I'd class Mullvad as the most serious VPN provider

I agree. Its annoying that lots of places have recently been blanket-banning Mullvad IP ranges.

Their sister-company Tilitis[1] is also doing interesting things with the Tkey product.

The present version has limitations due to the original security model but the up-and-coming version has a revised security model to make things a bit more "real-world" useful whilst not making any security trade-offs.

[1] https://www.tillitis.se/

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#105

Post by sam_lowry_ »

fragmede wrote: post #76
sam_lowry_ wrote: post #74

Earlier quoted context omitted.

There is a whole class of security issues where fixes are worse that the issues themselves . Case in point, the OpenSSH itself that sends 100 packets on each keystroke to avoid timing attacks.

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.

Because it breaks our mental model of how things work.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#107

Post by angry_octet »

semi-extrinsic wrote: post #63
OJFord wrote: post #53

Earlier quoted context omitted.

The SSH vulnerability here only applies if the attacker is already on the network. It violates your Tailscale ACLs, but it's not arbitrary external root ssh access. Arguably that's a more secure starting point than vanilla ssh to publicly accessible machine.

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).

Unless you're using short lived SSH CA certificates, SSH key access has only modest security. You would need to buttress it with TOTP 2FA or enforce Yubikey generation/storage of keys, neither of which are at all default.

Even then, it's obvious you are running SSH, and they can fingerprint the OS, and external logging shows which machines are connecting, and hence have said SSH keys. If they have SSH open they become targets; if they come from CGNAT, carriers can leak location via CGNAT behaviour.

In contrast tailscale makes this much harder.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#108

Post by doctorpangloss »

sva_ wrote: post #73
doctorpangloss wrote: post #37

Earlier quoted context omitted.

haha self hosted wireguard, an opportunity to find out AllowedIPs: 0.0.0.0/0 does the opposite of what you think it will do

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.

I see that you don't know what AllowedIPs does :)

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#109

Post by Bnjoroge »

traceroute66 wrote: post #87

At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…

Did you try Headscale? https://github.com/juanfont/headscale or netbird? The latter has been great for me.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#110

Post by nicman23 »

dust-jacket wrote: post #84
gear54rus wrote: post #75

Earlier quoted context omitted.

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.

But are there any good self-hosted wrappers? I ditched wireguard for tailscale for the ease of managing it. I'd much rather run my own independently but CBA with the config editing hassle.

tailscale is self-hostedable
Post reply on HN