OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001. Saving the day once again.
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
81–90 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#82Earlier quoted context omitted.
For a word like 'safe', or at least in CS, I would assume that the 'safe' one actually is 'safest'; that 'safer' is ehh it's not safe but it's an improvement on the unsafe one. It's saf er .
Similarly, safest is normal English means not completely safe, but more safe than the other options. So safe > safest > safer > safe-ish > unsafe.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#83And 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…
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#84Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#85And 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…
I use port knocking to keep my ssh logs clean. I dont think it adds security (I even brag about using it in public). It allows me to read ssh's logs without having to remove all the script kiddie login attempt spam.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#86Earlier quoted context omitted.
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
#87And 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…
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#88And 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…
It's not security theater but it's kind of outdated. Single Packet Authentication[0] is a significant improvement.
> How many exploits rendered cold dead in their tracks by port-knocking shall we need before people stop saying port-knocking is security theater?
Port knocking is one layer, but it shouldn't be the only one, or even a heavily relied upon one. Plenty of people might be in a position to see the sequence of ports you knock, for example.
Personally, I think if more people bothered to learn tools like SELinux instead of disabling it due to laziness or fear, that is what would stop most exploits dead. Containers are the middleground everyone attached to instead, though.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#89Earlier 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 > (…)