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

311–320 of 347 posts

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

#311

Post by theoma »

jamilbk wrote: post #217

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…

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

It's open source. If you feel you could do a better job, then by all means, go ahead and fork it.

You're not entitled to anything from open source developers. They're allowed to make mistakes, and they're allowed to have as many or as few maintainers/reviewers as they wish.

https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

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

#312

Post by lmm »

lilyball wrote: post #309
lmm wrote: post #271

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.

A function like strcmp() cannot assume that if it sees the same pointer multiple times that this pointer contains the same data, so there's no opportunity for doing any sort of caching of results. The JVM has a lot more flexibility here in that it's working with objects, not raw pointers to arbitrary memory.

> A function like strcmp() cannot assume that if it sees the same pointer multiple times that this pointer contains the same data

For arbitrary pointers no. But it could special-case e.g. string constants in the source code and/or pointers returned by some intern function (which is also how the JVM does it - for arbitrary strings, even though they're objects, it's always possible that the object has been GCed and another string allocated at the same location).

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

#313

Post by remram »

DEADMINCE wrote: post #97
mmsc wrote: post #68

Earlier quoted context omitted.

How is it not? If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.

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.

You could have also said "99% of people don't let their login timeout and hit the SIGALRM"... People don't usually use an SSH RCE because there usually isn't an SSH RCE. If there is, why wouldn't they?

It doesn't matter if 99% of the situations you can think of are not problematic. If 1% is feasible and the attackers know about it, it's an attack vector.

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

#314

Post by remram »

Sparkyte wrote: post #272

People still use SSH these days? I kid, but really you probably shouldn't on Production. You should be exporting your logs and everything else. The host or VM bootstrapped golden images with everything as needed. It is okay to start that way and figure out your enternals but that isn't for Production. Production is a locked down closed environment. Recomment from another Hacker News post.

Yes I too have production systems running no software at all.

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

#315

Post by remram »

someplaceguy wrote: post #159
lupusreal wrote: post #128

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

> The bet is that a compromise in both the service and wireguard at the same time is unlikely An RCE in wireguard would be enough -- no need to compromise both.

I was going to say something like this, but in practice wireguard is very very tiny. It doesn't have pluggable authentication, or passwords, or user transitions, or forked subprocesses, or systemd integrations. Using it or another simple secure transport in front of SSH is probably a good idea.

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

#316

Post by someplaceguy »

remram wrote: post #315
someplaceguy wrote: post #159

Earlier quoted context omitted.

> The bet is that a compromise in both the service and wireguard at the same time is unlikely An RCE in wireguard would be enough -- no need to compromise both.

I was going to say something like this, but in practice wireguard is very very tiny. It doesn't have pluggable authentication, or passwords, or user transitions, or forked subprocesses, or systemd integrations. Using it or another simple secure transport in front of SSH is probably a good idea.

I don't disagree with you. However, my point was that the parent poster's reasoning was flawed.

Stacking these services on top of each other in this way does not necessarily mean that an attacker has to compromise both services in order to compromise a host. The parent poster's flawed reasoning appeared to lead to a false sense of security as a result.

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

#317

Post by rfoo »

px43 wrote: post #220
SoftTalker wrote: post #184

Earlier quoted context omitted.

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.

No. You can't protect against arbitrary "memory corruption" without also covering race condition.

While this is a common misconception, I'm already tired of enthusiastic "safu language fans" trying to explain what bound checks mean to me so apologizes for being mean.

But no, in 2024 you should focus on temporal memory safety which is much harder to eliminate compared to "just add boundz CHK everYwHErE!!!@".

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

#318

Post by paulmd »

JackSlateur wrote: post #279
paulmd wrote: post #243

Earlier quoted context omitted.

> KPTI won't be default enabled on Linux on AMD CPUs is the issue here. Yet it provides valuable separation between kernel and userspace address ranges. AMD's security bulletin is actually incredibly weaselly and in fact quietly acknowledges KPTI as the reason further mitigation is not necessary, and then goes on to recommend that KPTI remain disabled anyway. https://www.amd.com/en/resources/product-security/bulletin…

But is this not the same thing on intel CPU ? I believe "new" intel CPU are, too, unaffected by meltdown, and so kpti will be disabled there by default.

if there are no errata leading to (FG)KASLR violations, then no problem disabling KPTI as a general security boundary. The thing I am saying is that vendors do not agree on processors providing ASLR timing attack protection as a defined security boundary in all situations.

you need to either implement processor-level ASLR protections (and probably these guarantees fade over time!) or kpti/flush your shit when you move between address spaces. Or there needs to be an understanding from the kernel team that they need to develop under the page allocation model that attackers can see your allocation patterns after initial breaches. like let's say they breach your PRNG key. Should there be additional compartmentalization after that? Multiple keys at multiple security boundaries / within the stack more generally to increase penetration time across security boundaries?

seemingly the expectation is one or the other though, because ASLR security is being treated as a security boundary.

I also very much feel that at this point KPTI is just a generalized good defense in depth. If that's the defense that's going to be deployed after your shit falls through... let's just flush it preemptively, right? That's not the current practice but should it be?

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

#320

Post by SomeoneFromCA »

jcul wrote: post #300
SomeoneFromCA wrote: post #291

Earlier quoted context omitted.

Contrived example, never seen in reality.

You could be surprised. For example, recently I wanted to call `gettid()` in a signal handler. Which I guessed was just a simple wrapper around the syscall. However, it seems this can cache the thread ID in thread local storage (can't remember exact details). I switched to making a syscall instead.

Well, this is possible for sure, but not for primitive functions, such as strcmp. It just does not happen in practice.
Post reply on HN