301–310 of 347 posts
Earlier quoted context omitted.
https://github.com/francoismichel/ssh3?tab=readme-ov-file
>However, we cannot yet endorse its appropriateness for production systems without further peer review. [0] Not an alternative and won't be for the foreseeable future. [0]: https://github.com/francoismichel/ssh3?tab=readme-ov-file#-s...
From 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…
Earlier quoted context omitted.
Has this fix been pushed to / pulled by distributions yet?
Fedora: not yet. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-6387 (tracking task) https://bugzilla.redhat.com/show_bug.cgi?id=2294905 (Fedora 39 issue)
Earlier quoted context omitted.
>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.
> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all
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?
Earlier quoted context omitted.
> surely it doesn't touch any global (or per-thread) state Not necessarily. An implementation might choose to e.g. use some kind of cache similar to what the JVM does with interned strings, and then a function like strcmp() might behave badly if it happened to run while that cache was halfway through being rebuilt.
Contrived example, never seen in reality.
Earlier 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…
That's the point. They weren't added until TC2 in 2016.
Earlier 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…
> surely it doesn't touch any global (or per-thread) state Not necessarily. An implementation might choose to e.g. use some kind of cache similar to what the JVM does with interned strings, and then a function like strcmp() might behave badly if it happened to run while that cache was halfway through being rebuilt.
Earlier quoted context omitted.
>scp, among other things, runs over ssh. Ironically scp/sftp caused me more bandwidth headaches than wireguard/openvpn. I frequently experienced cases where scp/sftp would get 10% or even less of the transfer speed compared to a plain http(s) connection. Maybe it was due to packet loss, buffer size, or qos/throttling, but I wasn't able to figure out a definitive solution.
In almost all cases, the reason is OpenSSH's silly limitation of buffer sizes [1]. It limits the amount of data that's "in the cable" (which needs to be more if the cable is long). > The default SSH window size was 64 - 128 KB, which worked well for interactive sessions, but was severely limiting for bulk transfer in high bandwidth-delay product situations. > OpenSSH later increased the default SSH window size to 2 M…