7 comments

  • drnick1 0 minutes ago
    I'll stick to my 100% self-hosted Wireguard setup, thank you very much.
  • tptacek 1 hour ago
    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.)

    • RossBencina 18 minutes ago
      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?
    • iririririr 32 minutes ago
      you can also add parameters to env vars in some popular cloud providers for the same effect.
  • doublepg23 1 hour ago
    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.
    • dgacmu 41 minutes ago
      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.
    • jdiff 1 hour ago
      I've used it before to access my tailnet machines through a browser on a machine I can't download software on.
    • bakies 52 minutes ago
      Yeah pretty much just use tailscale as a vpn.. do one thing as they say.
    • isatty 1 hour ago
      Convenience for the most part but in general, I agree. I like having it as an option.
  • e40 1 hour ago
    So, giving access via tailscale but using OpenSSH is safe, right?
    • lugoues 1 hour ago
      Yes, this only involves their wrapper that is managed by ACL rules.
    • iririririr 34 minutes ago
      as much as handing control to a remote third part is, yes.
  • kbumsik 1 hour ago
    Why own numbering instead of CVE?
    • vngzs 1 hour ago
      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
      • bigfatkitten 33 minutes ago
        And sometimes it’s just impossible to get a CVE number in a reasonable amount of time, or indeed at all.
  • modeless 1 hour ago
    Tailscale SSH has caused me other problems in the past because it takes over port 22. I'm not a fan.
    • LeoPanthera 25 minutes ago
      That is what it's supposed to do, though. It's not a secret.
    • huflungdung 46 minutes ago
      [dead]
  • cyberax 1 hour ago
    > "Tailscale SSH now rejects usernames with leading dashes."

    Really? That's the fix?

    A proper fix is to use "--" to separate arguments.

    • valleyer 57 minutes ago
      A proper fix is not to shell out to a command at all; use getpwnam(3) or similar.
    • sedatk 1 hour ago
      Their fix just future-proofs it in case the same bug gets reintroduced.
      • cyberax 54 minutes ago
        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.

        • sedatk 36 minutes ago
          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.