Live data from Hacker News

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

qualys.com

321–330 of 347 posts

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

#321
post #24

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…

There are many wannabe security researchers who find issues that are definitely not exploitable, and then demand CVE numbers and other forms of recognition or even a bounty. For example, there might be an app that crashes when accepting malformed trusted input, but the nature of the app is that it's never intended to and realistically never will be exposed to an adversary. In most people's eyes, these are simply bugs…

This shows kind of a naive view of security. Many soft targets are believed to be safe from adversaries that absolutely are not and are used for escalation chains or access to data.

Hospitals often try to make this argument about unsecure MySQL connections inside their network for example. Then something like heart bleed happens and lo and behold all the "never see an adversary" soft targets are exfil.

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

#322

Earlier quoted context omitted.

> "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 unprivile…

> I don't know who "we" are. We are the people having this discussion. That should be obvious. It's kind of funny you accused me of pretending to be baffled, lol. The irony. You certainly had no issue discussing this top with me until I called out your claims/methodology as nonsense. > The question I asked another poster, where you decided to butt in, Welcome to the Internet! > regarded escalation from an unprivilege…

Not sure if you reflect at all over your own texts. You come off as projecting, incoherent and cognitively dissonant.

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

#324
post #315

Earlier quoted context omitted.

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.

Yes for sure. An RCE in the first is sufficient, or an auth bypass in the first and some other vulnerability in the second.

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

#325
post #15

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…

would cold-restarting sshd every hour also make this unlikely / harder to exploit?

not noticeably with the default config? you need to win a race that happens roughly every 120s

I guess you could restart every minute...

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

#326

Out of curiosity, does Windows have anything as disruptive as signals? I assume it is also not vulnerable, because SSH server there do not use glibc.

Yes, Windows has signals. No Windows, doesn’t have glibc. But don’t worry, msvcrt has its own vulnerabilities.

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

#327
post #311

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…

Strangely aggressive and unproductive response. GP has valid points. They are not acting entitled in any way.

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

#328

Earlier quoted context omitted.

> I don't know who "we" are. We are the people having this discussion. That should be obvious. It's kind of funny you accused me of pretending to be baffled, lol. The irony. You certainly had no issue discussing this top with me until I called out your claims/methodology as nonsense. > The question I asked another poster, where you decided to butt in, Welcome to the Internet! > regarded escalation from an unprivilege…

Not sure if you reflect at all over your own texts. You come off as projecting, incoherent and cognitively dissonant.

Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse.

https://news.ycombinator.com/newsguidelines.html

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

#329

Earlier quoted context omitted.

> "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 unprivile…

> I don't know who "we" are. We are the people having this discussion. That should be obvious. It's kind of funny you accused me of pretending to be baffled, lol. The irony. You certainly had no issue discussing this top with me until I called out your claims/methodology as nonsense. > The question I asked another poster, where you decided to butt in, Welcome to the Internet! > regarded escalation from an unprivilege…

You've been posting huge numbers of flamewar comments lately. That's not what HN is for, and destroys what it is for. If you keep this up, we're going to have to ban you. I don't want to do that, so if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules from now on, we'd appreciate it.

By the time a commenter gets to violating the site guidelines as egregiously as this, it's almost always the case that they should have stopped posting a lot sooner.

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

#330

Earlier quoted context omitted.

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

Please don't perpetuate flamewar comments on HN. It's not what this site is for, and destroys what it is for.

I don't see as much of it in your recent history, which is good, but it's not good to let yourself get sucked into this sort of tit-for-tat spat.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Post reply on HN