As someone who does unspeakable, but safe, things in signal handlers, I can confirm that it is easy to stray off the path of async-signal-safety.
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
141–150 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#142Earlier quoted context omitted.
> Okay, let's say if you know something useful with a better record. Oh, SEL4 is without any doubt useful , it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread . However, you seem to have taken my examples literally and missed my point, which is trying to judge the security of an OS by its vulnerabilities is a terrible, terrible approach. > but it does include everything o…
> Oh, SEL4 is without any doubt useful, it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread. There is a laptop running OpenIndiana illumos on my desk. I mean useful, though through the lens of my usecases (read: if it can't run a web browser or server, I don't generally find it useful). I've only really heard of seL4 being popular in embedded contexts (mostly cars?), not g…
> I mean useful, though through the lens of my usecases
Better to stick to standard definitions in the future so you won't have to explain your personal definitions later on.
> No, I think your examples were excellent for illustrating the differences in systems; you can get a more secure system by severely limiting how much it can do
So you not only missed the point but decided to take away an entirely different message. Interesting.
Yes, limiting attack surface is a basic security principle. The examples I gave were not to demonstrate this basic principle, but to show that trying to gauge security by amount of vulnerabilities is foolish.
> seL4 is a good choice for embedded systems, but in itself currently useless as a server OS
Plan 9 then. Or any of other numerous OS projects that have less vulns than OpenBSD and can meet your arbitrary definition of 'useful'. The point is that trying to measure security by vuln disclosures is a terrible, terrible method and only something someone with no clue about security would use.
> but OpenBSD is a weirdly good ratio of high utility for low security exposure.
OpenBSD is just niche, that's it. Creating OpenSSH brought a lot of good marketing, but if you really look at the OS from a security perspective and look at features, it's lacking.
> Well no, that's the point - they'll be better than "fat" distros, but they absolutely will not match OpenBSD.
They absolutely will be better than OpenBSD, because they have capabilities to limit what an attacker can do in the event they get access, as opposed to putting all the eggs in the 'find all the bugs before they get exploited' basket. OpenBSD isn't anything special when it comes to security. That, really, is the point. Anything otherwise is marketing or people who have fell for marketing IMO.
> I don't really do youtube
There's a lot of good content only on that platform. Surely you can use yt-dlp or freetube or something.
> is it the one that handwaves at allegedly bad design without ever actually showing a single exploit?
That summary isn't remotely accurate, so I'd have to say no.
> Because I've gotten really tired of people loudly proclaiming that this thing is so easy to exploit but they just don't have time to actually do it just now but trust them it's definitely easy and a real thing that they could do even though somehow it never seems to actually happen.
They have remote holes listed on their homepage. Both those cases led to remote root and this supposedly secure OS had nothing to offer, while most Linux distros did. Let's make this simple. Linux allows you to contain a remote root exploit with tools like RBAC and MAC extensions. OpenBSD offers nothing. In the event both systems have the same vulnerability (of which this titular instance is not an example of) allowing remote root, Linux will be the safer system if set up correctly.
But honestly, I've gotten really tired of OpenBSD stans regurgitating that it's supposedly secure and thinking that being able to point to a lack of vulnerabilities in a barebones default install is some kind of proof of that.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#143Earlier quoted context omitted.
>People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it wil…
> It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Right, which is almost none. www-data should be set to noshell 99% of the time. > or just locally for some reason). This is all that would be relevant, and this is also very rare.
Think “illegitimate” access to www-data. It’s very common on linux pentests to need to privesc from some lower-privileged foothold (like a command injection in an httpd cgi script). Most linux servers run openssh. So yes I would expect this turns out to be a useful privesc in practice.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#144From 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 ?
The bug is a race condition which is triggered by code which runs when the timeout expires and the SIGALRM handler is run. If there is no time limit, then the SIGALRM handler will never run, and the race doesn't happen.
(As the advisory notes, you do then have to deal with the DoS which the timeout setting is intended to avoid, where N clients all connect and then never disconnect, and they aren't timed-out and forcibly disconnected on the server end any more.)
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#145Earlier 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...
I am one of the people who see fail2ban as a nuisance for the average administrator. Average means that they know things on average and sooner or later fail2ban will block unexpectedly. Usually when you are away canoeing in the wilderness.
This is all a matter of threat and risk management. If you know what you are doing then fail2ban or portknocking is another layer on your security.
Security theater in my opinion is something else: nonsense password policies, hiding your SSID, whitelisting MACs, ...
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#146Yearly reminder to run your ssh server behind spiped.[1] [2] [3] [1] https://www.tarsnap.com/spiped.html [2] https://news.ycombinator.com/item?id=29483092 [3] https://news.ycombinator.com/item?id=28538750
What's the advantage of this relatively obscure tool compared to something standard like wireguard or stunnel?
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#147Earlier quoted context omitted.
> Okay, let's say if you know something useful with a better record. Oh, SEL4 is without any doubt useful , it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread . However, you seem to have taken my examples literally and missed my point, which is trying to judge the security of an OS by its vulnerabilities is a terrible, terrible approach. > but it does include everything o…
> Oh, SEL4 is without any doubt useful, it wouldn't be as popular and coveted if it wasn't, but I think you are trying to say widespread. There is a laptop running OpenIndiana illumos on my desk. I mean useful, though through the lens of my usecases (read: if it can't run a web browser or server, I don't generally find it useful). I've only really heard of seL4 being popular in embedded contexts (mostly cars?), not g…
I’m an OpenBSD fanboi, and the review of mitigations, their origins, efficacy, and history is well worth the time to watch or just review slides. Its not about some claim of vulz.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#148One interesting comment in the OpenSSH release notes
> Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#149Earlier 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.
I'm kind of surprised advocating calling any syscall other than signal to add the handler back again. It's been a long time since I looked at example code, but back in the mid 90s, everything I saw (and so informed my habits) just set a flag, listened to the signal again if it was something like SIGUSR1 and then you'd pick up the flag on the next iteration of your main loop. Maybe that's also because I think of a sig…
In practice when I tried it, I wasn't sold on signalfd's benefits over the 90s style self-pipe, which is reliably portable too. Either way, being able to handle signals in a poll loop is much nicer than trying to do any real work in an async context.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#150Earlier quoted context omitted.
> It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Right, which is almost none. www-data should be set to noshell 99% of the time. > or just locally for some reason). This is all that would be relevant, and this is also very rare.
Think “illegitimate” access to www-data. It’s very common on linux pentests to need to privesc from some lower-privileged foothold (like a command injection in an httpd cgi script). Most linux servers run openssh. So yes I would expect this turns out to be a useful privesc in practice.
> Think “illegitimate” access to www-data.
I get the point.
My point was the example being given is less than 1% of affected cases.
> It’s very common on linux pentests to need to privesc from some lower-privileged foothold
Sure. Been doing pentests for 20+ years :)
> So yes I would expect this turns out to be a useful privesc in practice.
Nah.