For my own setup, I'm looking into Path Aware Networking (PAN) architectures like SCION to avoid exposing paths to my sshd, without having to set up a VPN or port knocking.
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
101–110 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#102Now, how many remote exploit do we have in openbsd?
Two in living memory? If you know something with a better track record do speak up.
SEL4 and derivatives.
For starters.
And if you want to simply go by vulnerability counts, as though that meant something, let's throw in MenuetOS and TempleOS.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#103> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all
Ubuntu isn't affected _by this exploit_
as opposed to the other exploits not being discussed.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#104From the report: > Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory. Setting 'LoginGraceTime 0' in sshd_config file seems to mit…
Hang on, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html says > If the value is 0, there is no time limit. Isn't that worse ?
It sounds like at the end of the default 600 seconds is when the race condition occurs. Set no limit, and there is no end
> In our experiments, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 600 seconds (LoginGraceTime), it takes ~1 week on average to obtain a remote root shell.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#105Earlier quoted context omitted.
Two in living memory? If you know something with a better track record do speak up.
SEL4 and derivatives. For starters. And if you want to simply go by vulnerability counts, as though that meant something, let's throw in MenuetOS and TempleOS.
Okay, let's say if you know something useful with a better record. TempleOS doesn't have network, so while it's genuinely cool it's not useful to most people. MenuetOS does have network but poor software compatibility. I would actually love to see a seL4 distro but AFAIK it's pretty much only ever used as a hypervisor with a "real" (normal) OS under it, often (usually?) Linux-based. We can certainly consider to what degree OpenBSD is useful with just the base system, but it does include everything out of the box to be a web server with zero extra software added, including sshd in its native environment.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#106Earlier quoted context omitted.
Port knocking is a ludicrous security measure compared to the combination of: * configuring sshd to only listen over a Wireguard tunnel under your control ( or letting something like Tailscale set up the tunnel for you) * switching to ssh certificate authn instead of passwords or keys
Does Wireguard work in such a way that there is no trace of its existence to an unauthorized contacting entity? I used port knocking for a while many years ago, but it was just too fiddly and flaky. I would run the port knocking program, and see the port not open or close. If I were to use a similar solution today (for whatever reason), I'd probably go for web knocking. In my case, I didn't see it as a security measu…
That's one of the original design requirements for wireguard. Unless a packet is signed with the correct key, it won't respond at all.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#107And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…
[deleted]
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#108Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#109Earlier quoted context omitted.
Similarly, safest is normal English means not completely safe, but more safe than the other options. So safe > safest > safer > safe-ish > unsafe.
Wait, that seems backwards to me as a native English speaker. The superlative version feels more safe. Safest > Safe > (…)
One example to help think about this. Say you have 3 friends. Your friend Bob has a net worth of $1 - he is the least rich. Your friend Alex has a net worth $10 - he is richer. Another friend Ben has a net worth of $100 - he is the richest. Richest here is comparative against all 3 of them, but none of them are actually rich. Bill Gates is rich. Bezos is rich. Musk is rich. Someone with a net worth of $100 isn't.
You can still have comparisons between the rich too, so Bezos is richer than Gates and he's also the richest if you're just considering the pair. But add Musk to the mix, and he's no longer the richest.
I guess that last example looks like you have two attributes - rich as some objective "has a lot of money" and comparatively rich (richer, richest). For safe, it's kind of similar, except that as soon as you are saying one thing is safer than the other, then you are implicitly acknowledging that there are areas where the thing isn't safe, and if you're admitting that you can't also call it safe without contradicting yourself.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#110And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…
What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and brings potentially other benefits. In a world where tailscale etc. have made quality VPNs trivial to implement, why would I both with port knocking?
VPNs drop your bandwidth speeds by 50% on average. And if tailscale has to use a relay server, instead of a direct connection, bandwidth will drop by 70-80%.