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

21–30 of 157 posts

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

#21

Post by iririririr »

tptacek wrote: post #2

This is such a venerable and ancient class of bugs, going at least as far back as AIX 3. Glad to see they're still makin' 'em like they used to. (If you had SSH access to a host in your Tailscale ACL, you could log in as `-i` and get a root login.)

you can also add parameters to env vars in some popular cloud providers for the same effect.

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

#23

Post by RossBencina »

tptacek wrote: post #2

This is such a venerable and ancient class of bugs, going at least as far back as AIX 3. Glad to see they're still makin' 'em like they used to. (If you had SSH access to a host in your Tailscale ACL, you could log in as `-i` and get a root login.)

I'm somewhat alarmed that the context that this bug was running in was capable of root login. Is there a reason that an SSH login process would, by default, have enough capabilities to facilitate direct root login?

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

#25

Post by turbert »

sedatk wrote: post #8
cyberax wrote: 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.

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.

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

#27

Post by turbert »

sedatk wrote: post #18
cyberax wrote: post #14

Earlier quoted context omitted.

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…

> I argue the opposite: there’s no better fix for this

The better fix would be to not have the username pass through a parser looking for cli flags in the first place.

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

#28

Post by yjftsjthsd-h »

RossBencina wrote: post #23
tptacek wrote: post #2

This is such a venerable and ancient class of bugs, going at least as far back as AIX 3. Glad to see they're still makin' 'em like they used to. (If you had SSH access to a host in your Tailscale ACL, you could log in as `-i` and get a root login.)

I'm somewhat alarmed that the context that this bug was running in was capable of root login. Is there a reason that an SSH login process would, by default, have enough capabilities to facilitate direct root login?

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.

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

#30

Post by cevn »

iririririr wrote: post #19
e40 wrote: post #3

So, giving access via tailscale but using OpenSSH is safe, right?

as much as handing control to a remote third part is, yes.

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