Live data from Hacker News

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

tailscale.com

11–20 of 157 posts

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

#11

I’m a heavy Tailscale user, so I do trust them quite a bit, but I never used the Tailscale SSH feature. I feel like OpenSSH’s security record is pretty unbeatable, not sure why I’d swap over for such a security-sensitive tool.

I've used it before to access my tailnet machines through a browser on a machine I can't download software on.

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

#12

I’m a heavy Tailscale user, so I do trust them quite a bit, but I never used the Tailscale SSH feature. I feel like OpenSSH’s security record is pretty unbeatable, not sure why I’d swap over for such a security-sensitive tool.

Convenience for the most part but in general, I agree. I like having it as an option.

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

#13
post #7

> "Tailscale SSH now rejects usernames with leading dashes." Really? That's the fix? A proper fix is to use "--" to separate arguments.

A proper fix is not to shell out to a command at all; use getpwnam(3) or similar.

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

#14
post #8
post #7

> "Tailscale SSH now rejects usernames with leading dashes." Really? That's the fix? A proper fix is to use "--" to separate arguments.

Their fix just future-proofs it in case the same bug gets reintroduced.

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.

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

#15

I’m a heavy Tailscale user, so I do trust them quite a bit, but I never used the Tailscale SSH feature. I feel like OpenSSH’s security record is pretty unbeatable, not sure why I’d swap over for such a security-sensitive tool.

Yeah pretty much just use tailscale as a vpn.. do one thing as they say.

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

#17

I’m a heavy Tailscale user, so I do trust them quite a bit, but I never used the Tailscale SSH feature. I feel like OpenSSH’s security record is pretty unbeatable, not sure why I’d swap over for such a security-sensitive tool.

I used it for a bunch of remote monitor boxes to have a way of centrally managing ssh access to things that were often on- and off-line. It was simple and convenient and access was easily revocable.

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

#18
post #14
post #8

Earlier quoted context omitted.

Their fix just future-proofs it in case the same bug gets reintroduced.

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.

I argue the opposite: there’s no better fix for this. You can write the most elegant fix, whatever it is, and prevent that from happening only on the codebase that’s fixed. That doesn’t mean that the codebase will always be the only authority on authentication.

The username policy fixes this issue for good, regardless of whatever you write in the future, or whatever new mechanism is introduced.

It’s a restriction for sure, but it’s not a nonsense restriction? Who would have a username starting with a hyphen? I didn’t even know it was possible until today.

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

#20
post #6
post #5

Why own numbering instead of CVE?

It lets organizations (Tailscale) control the timing and narrative around the disclosure more directly. Organizations sometimes avoid the bureaucracy of going through CVE Numbering Authorities by self-publishing. Often a CVE assignment follows self-disclosure, especially when there's pressure to interoperate with vuln-scanning/compliance tooling

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