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

211–220 of 347 posts

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

#211

Post by password4321 »

JackSlateur wrote: post #161
TacticalCoder wrote: post #62

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

Port-knocking is a PITA in theory and even worse in real world : people do not have time nor the will to do wild invocations before getting job done. Unless you are talking about your own personal use-case, in which case, feel free to follow your deepest wishes Firewall is a joke, too. Who can manage hundreds and thousands of even-changing IP ? Nobody. Again: I'm not talking about your personal use-case (yet I enjoy…

I am interested in any tools for managing IP allow lists on Azure and AWS. It seems like there should be something fairly polished, perhaps with an enrollment flow for self-management and a few reports/warnings...

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

#212

Post by indigodaddy »

chasil wrote: post #167
zshrc wrote: post #50

Earlier quoted context omitted.

Doesn’t affect RHEL7 or RHEL8.

Or RHEL9. $ rpm -q openssh openssh-8.7p1-38.0.1.el9.x86_64

Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable.

The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1

https://blog.qualys.com/vulnerabilities-threat-research/2024...

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

#213

Post by loeg »

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…

Has this fix been pushed to / pulled by distributions yet?

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

#214

Post by pornel »

SoftTalker wrote: post #184
fullspectrumdev wrote: post #178

Earlier quoted context omitted.

There’s a Rust library that implements most of the protocol, but I’ve not found a “drop in replacement” using said library yet. Might actually make for a fun side project to build a SSH server using that library and see how well it performs.

Does Rust have some invulnerability to race conditions?

It does have invulnerability to data races. However, that guarantee applies only to data types and code in Rust.

The dangerous interaction between signals and other functions is outside of what Rust can help with.

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

#216

Post by sisk »

acatton wrote: post #188
gruez wrote: post #146

Earlier quoted context omitted.

What's the advantage of this relatively obscure tool compared to something standard like wireguard or stunnel?

* The tool is not obscure, it's packaged in most distributions.[1][2][3] It was written and maintained by Colin Percival, aka "the tarnsnap guy" or "the guy who invented scrypt". He is the security officer for FreeBSD. * spiped can be used transparently by just putting a "ProxyCommand" in your ssh_config. This means you can connect to a server just by using "ssh", normally. (as opposed to wireguard where you need to…

> The private key is much easier to set up than stunnel's TLS certificate, "dd if=/dev/urandom count=4 bs=1k of=key" and you're good to go.

The spiped documentation recommends a key size with a minimum of 256b of entropy. I'm curious why you've chosen such a large key size (4096b) here? Is there anything to suggest 256b is no longer sufficient for the general case?

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

#217

Post by jamilbk »

From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this:

  void
  sigdie(const char *fmt,...)
  {
  #ifdef DO_LOG_SAFE_IN_SIGHAND
   va_list args;
  
   va_start(args, fmt);
   do_log(SYSLOG_LEVEL_FATAL, fmt, args);
   va_end(args);
  #endif
   _exit(1);
  }
to this:

  void
  sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
  {
   va_list args;
  
   va_start(args, fmt);
   sshlogv(file, func, line, 0, SYSLOG_LEVEL_FATAL, fmt, args);
   va_end(args);
   _exit(1);
  }
which lacks the #ifdef.

What could have prevented this? More eyes on the pull request? It's wild that software nearly the entire world relies on for secure access is maintained by seemingly just two people [2].

[1] https://github.com/openssh/openssh-portable/commit/752250caa...

[2] https://github.com/openssh/openssh-portable/graphs/contribut...

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

#218

Post by Arnavion »

chasil wrote: post #196
Ianvdl wrote: post #180

Earlier quoted context omitted.

> Statement > The flaw affects RHEL9 as the regression was introduced after the OpenSSH version shipped with RHEL8 was published.

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 can't test it right now though so I may be missing something.

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

#219

Post by yjftsjthsd-h »

DEADMINCE wrote: post #132
yjftsjthsd-h wrote: post #121

Earlier quoted context omitted.

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.

I'm not sure that's fair; was log4j a vulnerability in Ubuntu itself? How about libwebp ( https://news.ycombinator.com/item?id=37657746 )?

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

#220

Post by px43 »

SoftTalker wrote: post #184
fullspectrumdev wrote: post #178

Earlier quoted context omitted.

There’s a Rust library that implements most of the protocol, but I’ve not found a “drop in replacement” using said library yet. Might actually make for a fun side project to build a SSH server using that library and see how well it performs.

Does Rust have some invulnerability to race conditions?

This bug seems to be exploitable due to a memory corruption triggered by the race condition, it's the memory corruption that rust would protect from.
Post reply on HN