103 points figmert 1 hour ago 53 comments
wslh 1 hour ago | parent
_def 1 hour ago | parent
femiagbabiaka 1 hour ago | parent
forbiddenlake 1 hour ago | parent
seemaze 1 hour ago | parent
6thbit 1 hour ago | parent
> Most of the Tailscale SSH issues we've identified concern privilege escalation. In some circumstances, someone already authorized to connect over Tailscale SSH may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges.
"Most"? "In some circumstances"?
Makes me think that they could also be investigating a full on unauthorized connection issue, or am I reading too much into it?awildfivreld 1 hour ago | parent
drum55 43 minutes ago | parent
remus 1 hour ago | parent
devmor 1 hour ago | parent
pizzafeelsright 1 hour ago | parent
There is some weaselly language.
In some circumstances default config? with password? this is a condition leading to the next
someone already authorized to connect over Tailscale SSH they have access, but it may be limited or restricted, although scope could be beyond the intended
may be able to perform actions beyond the permissions If there is a full moon and your brother in law's second cousin is wearing a hat, he may be able to use your upstair's thermostat provided you have a second story.
fooqux 29 minutes ago | parent
traceroute66 17 minutes ago | parent
Quick reminder that in recent months Tailscale has had issues with age-old classic vulnerabilities such as input validation.
The problem with Tailscale is twofold.
First their attack surface is too big. They continuously shoehorn new features into the product.
Second they don't appear to do regular deep-dive code audits and instead they appear to rely mostly on the goodwill of third-parties to poke at select areas of their code as and when those third-parties feel like it. Hence simple vulnerabilities such as input validation keep on popping up.
Fancy SOC2 certificates are not the same thing. That's just dogfood for the corporate auditors.
At $work we are busy working on removing Tailscale. The bells and whistles of Tailscale sure are attractive candy, but we simply can't overlook the security risk of what has become a bloated product.
slowin 1 hour ago | parent
dist-epoch 1 hour ago | parent
> Organizations using headscale v0.29.5 have no mechanism to disable the forwarding behavior at the center of the finding.
https://techjacksolutions.com/scc-vendor-rollup/tailscale-he...
minimaltom 10 minutes ago | parent
wrxd 1 hour ago | parent
I wasn't using any of the additional features, I can get away with exposing a port on my router and I am changing devices rarely.
News like this make me happy I removed a lot of complexity and attack surface
femiagbabiaka 49 minutes ago | parent
using wireguard is awesome, but I wouldn't say deploying and maintaining it lacks complexity exactly. and you didn't get rid of attack surface, you just made it your responsibility ;)
swingandamiss 44 minutes ago | parent
femiagbabiaka 39 minutes ago | parent
swingandamiss 26 minutes ago | parent
arcanemachiner 38 minutes ago | parent
swingandamiss 27 minutes ago | parent
drum55 36 minutes ago | parent
LoganDark 40 minutes ago | parent
lakeviewterrace 34 minutes ago | parent
Gigachad 21 minutes ago | parent
LoganDark 14 minutes ago | parent
ectospheno 31 minutes ago | parent
F_r_k 26 minutes ago | parent
aborsy 1 hour ago | parent
I use it extensively, and I would rather pay them a fee if they could review thr code.
Another possibility is as lock down mode, disabling fancy and risky features.
drdexebtjl 18 minutes ago | parent
Does anyone know of a Tailscale alternative that sticks to the basics?
Something that’s just WireGuard but without the manual key exchange, and with Tailscale-like NAT hole-punching that falls back to using an oblivious relay?
Gigachad 16 minutes ago | parent
Good idea to set up automatic updates for the tailscale client though.
rietta 13 minutes ago | parent
Over the decades, I have maintained remote access through port forwarding on my router - at one point in 2008 I put SSH on port 80 so I could access it from the restricted wifi network at the hospital my grandmother was at. I have also used openvpn. I have also used cloudflare tunnels. But in the end, I always connect to hardened openssh with key only authentication.
minimaltom 12 minutes ago | parent
Having done my own review of the vulns and the fixes as they are landing in github, its pretty clear to me that this only affects situations where you use ACLs to permit ssh into a node (via tailscale ssh, not via opensshd), but dont give a path to sudoers/root.
If a user had no SSH access and/or connectivity to a vulnerable node, none of these vulns give them access.
However, if you have a vulnerable tailscaled and you give ssh access as some non-root account/privs, then yes, these vulns are relevant as theres now known privilege escalations that give access beyond some specific user account.
Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is.
hollow-moe 8 minutes ago | parent