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

221–230 of 347 posts

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

#221

Post by unixpickle »

fanf2 wrote: post #23
FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

That's not the RCE fix, this is the RCE fix https://news.ycombinator.com/item?id=40843865 That's a previously-announced feature for dealing with junk connections that also happens to mitigate this vulnerability because it makes it harder to win the race. Discussed previously https://news.ycombinator.com/item?id=40610621

These lines from the diff linked above are the fix:

    - /\* Log error and exit. \*/
    - sigdie("Timeout before authentication for %s port %d",
    -     ssh_remote_ipaddr(the_active_state),
    -     ssh_remote_port(the_active_state));
    + _exit(EXIT_LOGIN_GRACE);

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

#222

Post by matthewcroughan »

pgraf wrote: post #125
matthewcroughan wrote: post #101

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. https://scion-architecture.net

Genuinely curious, how would you block an attacker from getting to your SSH port without knowing the path you will connect from (which is the case for remote access) at configuration time? I don‘t see how Path-Aware Networking would replace a VPN solution

The SCION Book goes over a lot of potential solutions that are possible because of the architecture, but my favorite is hidden paths. https://scion.docs.anapaya.net/en/latest/hidden-paths.html

> Hidden path communication enables the hiding of specific path segments, i.e. certain path segments are only available for authorized ASes. In the common case, path segments are publicly available to any network entity. They are fetched from the control service and used to construct forwarding paths.

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

#224

Post by jonaslejon »

ttul wrote: post #117

TLDR: this vulnerability does appear to allow an attacker to potentially gain remote root access on vulnerable Linux systems running OpenSSH, with some important caveats: 1. It affects OpenSSH versions 8.5p1 to 9.7p1 on glibc-based Linux systems. 2. The exploit is not 100% reliable - it requires winning a race condition. 3. On a modern system (Debian 12.5.0 from 2024), the researchers estimate it takes: - ~3-4 hours…

OpenSSH 9.8p1 was released July 1, 2024 according to https://www.openssh.com/releasenotes.html#9.8p1

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

#225

Post by daneel_w »

DEADMINCE wrote: post #183
daneel_w wrote: post #170

Earlier quoted context omitted.

> I'm sorry, what? What kind of nonsense distinction is this? > Are you trying to very disingenuously try and claim only kernel exploits count as attacks against OpenBSD? Not at all. I clearly underlined that I'm not looking for cases fitting that specific scenario. The only moving of goalposts is entirely on your behalf by very disingenously misrepresenting my question in a poor attempt to try make your answer or wh…

> Not at all. I clearly underlined that I'm not looking for cases fitting that specific scenario The thing is, we're trying to talk about the security of OpenBSD compared to its competition. But you're trying to avoid letting anyone do that by saying only an attack against something in the default install you can do with a user account counts, which is absolutely ridiculous. I'm not moving the goalposts nor am I pret…

> "The thing is, we're trying to talk about the security of OpenBSD compared to its competition."

> "But you're trying to avoid letting anyone do that by saying only an attack against something in the default install you can do with a user account counts, which is absolutely ridiculous."

I don't know who "we" are. The question I asked another poster, where you decided to butt in, regarded escalation from an unprivileged position and nothing else.

Nobody but yourself said anything along the lines of "only attacks against things in the default install 'count'", nor drew drew up comparisons against "the competition". You clearly have some larger axe to grind, but you're doing it in a discourse playing out only in your head, without reading what others actually wrote.

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

#226

Post by betaby »

INTPenis wrote: post #43

Correct me if I'm wrong but it seems like sshd on RHEL-based systems is safe because they never call syslog. They run sshd with the -D option already, logging everything to stdout and stderr, as their systemd already catches this output and sends it to journal for logging. So I don't see anywhere they would be calling syslog, unless sshd does it on its own. At most maybe add OPTIONS=-e into /etc/sysconfig/sshd.

Same question. Aren't all systemd based distros use stdin/out/err for logging and won't call syslog?

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

#227

Post by aflukasz »

betaby wrote: post #207

In some setups I decided to have jumphost via HAproxy ssl as described there https://www.haproxy.com/blog/route-ssh-connections-with-hapr... so no ssh directly exposed at all.

So this is effectively like ProxyJump, just with the jump node exposed over SSL and backed by HAProxy binary instead of OpenSSH?

What benefits do you see? I mean, you still expose some binary that implements authentication and authorization using cryptography.

I think that even RBAC scenarios described in the link above should be achievable with OpenSSH, right?

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

#228

Post by brazzy »

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…

That sounds... familiar. Are you perchance the maintainer of SnakeYAML?

Yes, it is correct to file a CVE of the highest priority against your project, because "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library.

If it's your toy project that you never expected anyone to use anyway, you don't care about CVEs. If you want to be taken seriously, you cannot play pass-the-blame and ignore the fact that your policy turns the entire project into a security footgun.

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

#229

Post by Elucalidavah »

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…

> Imagine I make a serialisation/deserialisation library which would be vulnerable if you fed it untrusted data

No need to imagine, the PyYAML has that situation. There have been attempts to use the safe deserialization by default, with an attempt to release a new major version (rolled back), and it settled on having a required argument of which mode / loader to use. See: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=PyYAML

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

#230

Post by chasil »

Arnavion wrote: post #218
chasil wrote: post #196

Earlier quoted context omitted.

However, we see the -D option on the listening parent: $ ps ax | grep sshd | head -1 1306 ? Ss 0:01 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups As mentioned elsewhere here, is -D sufficient to avoid exploitation, or is -e necessary as well? $ man sshd | sed -n '/ -[De]/,/^$/p' -D When this option is specified, sshd will not detach and does not become a daemon. This allows easy monitoring of sshd. -e Write…

>As mentioned elsewhere here, is -D sufficient to avoid exploitation, or is -e necessary as well? https://github.com/openssh/openssh-portable/blob/V_9_8_P1/ss... sshd.c handles no_daemon (-D) and log_stderr (-e) independently. log_stderr is what is given to log_init in log.c that gates the call to syslog functions. There is a special case to set log_stderr to true if debug_flag (-d) is set, but nothing for no_daemon.…

I'm on Oracle Linux, and they appear to have already issued a patch for this problem:

  openssh-8.7p1-38.0.2.el9.x86_64.rpm
  openssh-server-8.7p1-38.0.2.el9.x86_64.rpm
  openssh-clients-8.7p1-38.0.2.el9.x86_64.rpm
The changelog addresses the CVE directly. It does not appear that adding the -e directive is necessary with this patch.

  $ rpm -q --changelog openssh-server | head -3
  * Wed Jun 26 2024 Alex Burmashev  - 8.7p1-38.0.2
  - Restore dropped earlier ifdef condition for safe _exit(1) call in sshsigdie() [Orabug: 36783468]
    Resolves CVE-2024-6387
Post reply on HN