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

201–210 of 347 posts

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

#201

Post by jmclnx »

megous wrote: post #2

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). MaxStartups default is 10

The default for MaxStartups is 10:30:100

10:30:60 is mentioned in the man for start:rate:full, so I set mine to that value.

Thanks for the quote

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

#202

Post by cesarb »

rwmj wrote: post #134
fanf2 wrote: post #35

Earlier quoted context omitted.

Exactly, yes :-) Signal handlers have so many hazards it's vital to keep them as simple as possible.

A rule I try to follow: either set a global variable or write to a self pipe (using the write syscall), and handle the signal in the main loop.

> either set a global variable

IIRC, the rule is also that said global variable must have the type "volatile sig_atomic_t".

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

#203

Post by bhawks »

mananaysiempre wrote: post #129
singron wrote: post #113

Earlier quoted context omitted.

If you are right about the allocations, then I think the worst it can do is deadlock since the locks aren't recursive. Deadlock in sigalrm could still lead to a DOS since that might prevent it from cleaning up connections.

Heretical opinion: signal handler activations should count as separate threads for the purposes of recursive locking.

How would be done without introducing deadlock?

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

#204

Post by qhwudbebd »

qhwudbebd wrote: post #58

Once I'd finished upgrading my openssh instances (which are linked against musl not glibc) I thought it'd be interesting to have a poke at musl's syslog(3) and see if it allocates too and so is easily exploitable in the same way. But as far as I can see, it doesn't: https://github.com/bminor/musl/blob/master/src/misc/syslog.c Everything there is either on stack or in static variables protected from reentrancy by the…

Confirmation from Rich: https://fosstodon.org/@musl/112711796005712271

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

#205

Post by growse »

johnklos wrote: post #197
growse wrote: post #64

Earlier quoted context omitted.

What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and brings potentially other benefits. In a world where tailscale etc. have made quality VPNs trivial to implement, why would I both with port knocking?

Are you assuming that VPNs are more secure than ssh?

No?

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

#206

Post by mananaysiempre »

bhawks wrote: post #203
mananaysiempre wrote: post #129

Earlier quoted context omitted.

Heretical opinion: signal handler activations should count as separate threads for the purposes of recursive locking.

How would be done without introducing deadlock?

You’d get a deadlock, absolutely. But I’m fine with that: if the thread wants to access some state protected by a mutex, then while holding it (effectively) spawns a signal handler activation and waits for it to complete, and the signal handler tries to accept some state protected by the same mutex, then the program has just deadlocked (mutex → signal handler → mutex) and deserves to hang (or die, as this is a very simple situation as far as deadlock detection goes). That’s in any case better than corrupted state.

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

#208

Post by betaby »

acatton wrote: post #123

Yearly reminder to run your ssh server behind spiped.[1] [2] [3] [1] https://www.tarsnap.com/spiped.html [2] https://news.ycombinator.com/item?id=29483092 [3] https://news.ycombinator.com/item?id=28538750

I run sshd behind the HAProxy https://www.haproxy.com/blog/route-ssh-connections-with-hapr...

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

#209

Post by gruez »

jgalt212 wrote: post #199
gruez wrote: post #151

Earlier quoted context omitted.

>VPNs drop your bandwidth speeds by 50% on average Source? Wireguard can do 1GB/s on decade old processors[1]. Even openvpn can do 258 Mb/s, which realistically can saturate the average home internet connection. Also, if we're talking about SSH connections, why does throughput matter? Why do you need 1 gigabit of bandwidth to transfer a few keystrokes a second? [1] https://www.wireguard.com/performance/

We ran iperf on our multi-cloud and on prem network. > Also, if we're talking about SSH connections, why does throughput matter? scp, among other things, runs over ssh.

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

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

#210

Post by password4321 »

kraftverk_ wrote: post #137
poikroequ wrote: post #124

After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.

What do you use in place of it?

https://www.aurga.com/ ?

Because an $80 black box wireless KVM from a foreign country is way more secure! (Just kidding, though it is not internet-accesible by default.)

Post reply on HN