Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

qualys.com

Post reply on HN
Print view View original

131–140 of 347 posts

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#131

Post by ralferoo »

ralferoo wrote: post #109
p51-remorse wrote: post #82

Earlier quoted context omitted.

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…

A better example is "pure water". By it's definition, that's just H2O molecules floating around with nothing else.

If you add a single grain of salt to a glass of that water, it's no longer pure. Drinking it you probably wouldn't notice, and some people might colloquially call it "pure", but we know it isn't because we added some salt to it.

If you add a teaspoon of salt to to a different glass of pure water, it's also no longer pure, and now most people would probably notice the salt and recognise it's not pure.

If you add a tablespoon of salt to to a different glass of pure water, it's definitely not pure and you probably wouldn't want to drink it either.

You could say the teaspoon of salt glass is purer than the tablespoon of salt glass, the grain of salt glass is purer than both of them and so the purest of the three. And yet, we know that it isn't pure water, because we added something else to it.

So pure > purest > purer > less pure. Also note that I was required to use "less pure" for the last one, because all of them except pure are "impure" or "not pure", even though were what I originally thought of writing.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#132

Post by DEADMINCE »

yjftsjthsd-h wrote: post #121
daneel_w wrote: post #115

Earlier quoted context omitted.

> Sure, see any of the previous exploits for sshd, or any other software shipped in the OpenBSD default install. Would you like to point to one that successfully utilizes a weakness in OpenBSD itself , which is the topic and implied statement of the video, rather than a weakness in some application running under the superuser? Just to underline, I'm not interested in discussing the hows and whys of containing arbitra…

Now to be fair, sshd on OpenBSD is part of OpenBSD rather than an add-on application and I think it would be fair to count exploits in it against the OS, if it had vulnerabilities there.

Any vulns in any package in OpenBSD's package repositories that they audited should count as a vuln against OpenBSD itself.

If OpenBSD users installed it through OpenBSD repositories and are running it will they be affected? Yes? Then it counts against the system itself.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#133

Post by rwmj »

poikroequ wrote: post #124

After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.

So .. how do you handle remote logins?

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#134

Post by rwmj »

fanf2 wrote: post #35
djmdjm wrote: post #28

Earlier 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.

A rule I try to follow: either set a global variable or write to a self pipe (using the write syscall), and handle the signal in the main loop.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#136

Post by DEADMINCE »

mmsc wrote: post #120
DEADMINCE wrote: post #97

Earlier 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. But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.

>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.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#137

Post by kraftverk_ »

poikroequ wrote: post #124

After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.

What do you use in place of it?

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#138

Post by hgs3 »

theandrewbailey wrote: post #55
0x0 wrote: post #4

Patch out for Debian 12; Debian 11 not affected. https://security-tracker.debian.org/tracker/CVE-2024-6387

Just ran an apt update and upgrade on my Debian 12 server. OpenSSH packages were the only ones upgraded.

Yes, the Debian 12 fix is out. You can verify you're patched by running 'ssh -V' and verifying you see 'deb12u3'. If you see 'deb12u2' then you're vulnerable [1].

[1] https://security-tracker.debian.org/tracker/CVE-2024-6387

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#139

Post by mtrantalainen »

michaelt wrote: post #41
CJefferson wrote: post #21

This 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…

> Maybe at the moment there are just too many little issues, that you need a full end-to-end hack to really convince people to take you seriously, or pay out bounties? Let me give you a different perspective. Imagine I make a serialisation/deserialisation library which would be vulnerable if you fed it untrusted data. This is by design, users can serialise and deserialise anything, including lambda functions. My libr…

I think that if the documented interface of your library is "trusted data only", then one shouldn't even file a bug report against your library if somebody passes it untrusted data.

However, if you (or anybody else) catch a program passing untrusted data to any library that says "trusted data only", that's definitely CVE worthy in my books even if you cannot demonstrate full attack chain. However, that CVE should be targeted at the program that passes untrusted data to trusted interface.

That said, if you're looking for bounty instead of just some publicity in reward for publishing the vulnerability, you must fullfil the requirements of the bounty and those typically say that bounty will be paid for complete attack chain only.

I guess that's because companies paying bounties are typically interested in real world attacks and are not willing to pay bounties for theoretical vulnerabilities.

I think this is problematic because it causes bounty hunters to keep theoretical vulnerabilities secret and wait for possible future combination of new code that can be used to attack the currently-theoretical vulnerability.

I would argue that it's much better to fix issues while they are still theoretical only. Maybe pay lesser bounty for theoretical vulnerabilities and pay reduced payment for the full attack chain if it's based on publicly known theoretical vulnerability. Just make sure that the combination pays at least equally good to publishing full attack chain for 0day vulnerability. That way there would be incentive to publish theoretical vulnerabilities immediately for maximum pay because otherwise somebody else might catch the theoretical part and publish faster than you can.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#140

Post by NelsonMinar »

jesprenj wrote: post #12

> 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.

[flagged]
Post reply on HN