Now, 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.
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
61–70 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#62And 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-knocking is not "security theater": it adds one layer of defense. It's defense-in-depth. Not theater.
And the port-knocking sequence doesn't have to be always the same: it can, say, change every 30 seconds, using TOTP style secret sequence generation.
How many exploits rendered cold dead in their tracks by port-knocking shall we need before people stop saying port-knocking is security theater?
Other measures do also help... Like restrictive firewalling rules, which many criticize as "it only helps keep the logs smaller": no, they don't just help keep the logs smaller. I'm whitelisting the three ISP's IP blocks anyone can reasonably be needing to SSH from: now the attacker needs not only the zero-day, but it also need to know he needs to be on one of those three ISPs' IPs.
The argument that consists in saying: "sshd is unexploitable, so nothing else must be done to protect the server" is...
Dead.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#63And 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…
Those not notoriously exploitable were those using gated ssh access only via known IPs or connecting via tailnets/vpn.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#64And 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?
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#65Earlier quoted context omitted.
Such an amount of connections should anyway trigger all possible logging & IDS systems, right?
It should trigger fail2ban, that's for sure. Alerting is useless, with the volume of automated exploits attempted.
> It should trigger fail2ban, that's for sure.
But people here are going to explain that fail2ban is security theater...
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#66Earlier quoted context omitted.
Theo de Raadt made an, I think, cogent observation about this bug and how to prevent similar ones: no signal handler should call any function that isn't a signal-safe syscall. The rationale is that, over time, it's too way easy for any transitive call (where it's not always clear that it can be reached in signal context) to pick up some call that isn't async signal safe.
Exactly, yes :-) Signal handlers have so many hazards it's vital to keep them as simple as possible.
I'm not overly familiar with the language and tooling ecosystem, but how trivial is this to detect on a static analysis?
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#67And 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…
Sure, if you can't afford a more robust access control to your SSH server and for some reason need to make it publicly available then port knocking etc. can be a deterring feature that reduces the attack rate.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#68Earlier quoted context omitted.
>Mitigate by using fail2ban? In theory, this could be used (much quicker than the mentioned days/weeks) to get local privilege escalation to root, if you already have some type of shell on the system already. I would assume that fail2ban doesn't block localhost.
How is local privilege escalation relevant here? Fail2ban should be able to block the RCE
How is it not?
If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#69This is a really good find. One thing which (as an independant person, who isn't doing any of the work!) is it often feels like in order to 'win', people are expected to find a full chain which gives them remote access, rather than just finding one issue, and getting it fixed / getting paid for it. It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape. Maybe at th…
> It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape.
It should be.
> Maybe at the moment there are just too many little issues...
There are so many.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#70This is a really good find. One thing which (as an independant person, who isn't doing any of the work!) is it often feels like in order to 'win', people are expected to find a full chain which gives them remote access, rather than just finding one issue, and getting it fixed / getting paid for it. It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape. Maybe at th…
There are many wannabe security researchers who find issues that are definitely not exploitable, and then demand CVE numbers and other forms of recognition or even a bounty. For example, there might be an app that crashes when accepting malformed trusted input, but the nature of the app is that it's never intended to and realistically never will be exposed to an adversary. In most people's eyes, these are simply bugs…
Agreed, I've seen all kinds of insane stuff, like "setting this public field of a java class to a garbage value will cause a null pointer exception"