how to install openssh 9.8p1 in ubuntu 22.04.4 LTS
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
281–290 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#282Earlier 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.…
So in other words, -De is not a workaround. -Dde might be but it will cause more log output than is wanted.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#283If you are on GCP and don't have time to patch, GCP recommends turning off your port 22 for now. https://cloud.google.com/compute/docs/security-bulletins
1. Find things that are 0.0.0.0 port 22, example, https://gist.github.com/james-ransom/97e1c8596e28b9f759bac79...
2. Force them to the local network, gcloud compute firewall-rules update default-allow-ssh --source-ranges=10.0.0.0/8 --project=$i;
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#284Earlier quoted context omitted.
This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawy…
Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe a…
> but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state?
On x86 and some other (mostly extinct) architectures that have string instructions, the string functions are usually best implemented using those (you might get a generation where there's a faster way and then microcode catches back up). And specifically (not just?) on x86 there was/is some confusion about who should or would restore some of the flags that control what these do. So you could end up with e.g. a memcpy or some other string instruction being interrupted by a signal handler and then it would continue doing what it did, but in the opposite direction, giving you wrong results or even resulting in buffer overflows (imagine interrupting a 1 MB memcpy that just started and then resuming it in the opposite direction).
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#285Earlier quoted context omitted.
Looks like Focal (20.04) isn't on an affected version. Jammy (22.04) looks like it is.
What about, uh, 18.04? Edit: 18.04 Bionic is unaffected, the ssh version is 7.6 which is too old.
I have a single 18.04 machine that is stuck on that, because it has 18.04 386, and as 20.04 doesn't support 386 anymore, apparently there is not a simple upgrade path to 20.04 64-bit (without doing extensive surgery). Very annoying...
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#286Earlier quoted context omitted.
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’ve written a few toy port knocking implementations, and doing it right is hard . If your connections crap and there’s packet loss, some of the sequence may be lost. Avoiding replay attacks is another whole problem - you want the sequence to change based on a shared secret and time or something similar (eg: TOTP to agree the sequence). Then you have to consider things like NAT…
Also, if you are trying to connect to a resource from a restrictive network your knocking sequence might be blocked by filters at the client end.
I've been on networks that allow nothing except the standard TCP & UDP ports for HTTP(S), SSH and DNS (and even then DNS was restricted to their local name server).
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#287From 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…
OpenBSD refactored their system to use async signal safe re-entrent syslog functions, so it’s possible that the author of this code simply assumed that it was safe to make this change, forgetting (or completely unaware) that other platforms (which the openBSD ssh devs don’t actually claim to support) were still using async unsafe functions.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#288Earlier quoted context omitted.
I now only bind services to wireguard interfaces. The bet is that a compromise in both the service and wireguard at the same time is unlikely (and I have relatively high confidence in wireguard.)
I'm confident in making ssh changes while logged in via ssh. Compared to ssh, wireguard configs feel too easy to mess up and risk getting locked out if its the only way of accessing the device.
Use tailscale instead? It’s user friendly enough that you’re unlikely to mess it up.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#289TLDR: 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…
> 4. It requires certain conditions: - The system must be using glibc (not other libc implementations) - 100 simultaneous SSH connections must be allowed (MaxStartups setting) - LoginGraceTime must be set to a non-zero value (default is 120 seconds)
Stupid question, perhaps, but if those two lines inside the sshd_config are commented out with '#', does this mean that grace period and max. sessions are technically unlimited and therefore potentially vulnerable?
Found my own answer: If the values are commented out, it means that the default values are being used. If the file hasn't been modified the default values are those you see inside the config file.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#290Earlier quoted context omitted.
Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe a…
> but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? On x86 and some other (mostly extinct) architectures that have string instructions, the string functions are usually best implemented using those (you might get a generation where there's a faster way and then microcode catches back up). And specifically (not just?) on x86 there was/is some confusion about who should o…
Make no sense to me. OS restores all the registers incl. flags after leaving the signal handler. Besides, your scenario is not related to the handler _itself_ calling memcpy; it is about interrupting the main code. And it never ever destroys flags.