91–100 of 157 posts
> "Tailscale SSH now rejects usernames with leading dashes." Really? That's the fix? A proper fix is to use "--" to separate arguments.
“--“ doesn’t work on all versions of getent. A better fix is to call “getent passwd” with no user controlled arguments and then parse the resulting list. This gets rid of the input sanitization problem entirely.
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…
Tailscale contracts with cybersecurity firm Latacora to conduct traditional assessments, advisory services, design reviews, auditing and testing. https://tailscale.com/security
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 !
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…
Spoiler alert: This applies to all software. This is why security preaches defense in depth.
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?
Earlier quoted context omitted.
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…
My WireGuard uses (either at home or at work) are very much mobile client to single network Where Tailscale comes into its own is automatic managing of mesh networking (like an “sdwan” solution). The other thing it excels at is firewall busting - if you have a firewall (with or without address translation) which only allows outgoing traffic to be established (with UDP timeouts for session) then Tailscale also works i…
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…
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…
>We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery 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.
Earlier quoted context omitted.
Tailscale contracts with cybersecurity firm Latacora to conduct traditional assessments, advisory services, design reviews, auditing and testing. https://tailscale.com/security
> 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…
Earlier quoted context omitted.
I don't mind having a bulletin so much as the claim that it's fixed in 1.98.9 or newer, when that release doesn't appear to exist yet. Feels pretty weird practice to advise upgrading to a non-existent version.
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
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…
Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22 to the internet and allow public key authentication only (or, certificate based one, if you prefer fancy)? OpenSSH security track record seems to be better than that of Tailscale.
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. ;)