Hacker News Reader

Comment by rfmoz | Hacker News Reader

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 mitigate the issue.

View on HN

Hang on, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html says

> If the value is 0, there is no time limit.

Isn't that worse?

The bug is a race condition which is triggered by code which runs when the timeout expires and the SIGALRM handler is run. If there is no time limit, then the SIGALRM handler will never run, and the race doesn't happen.

(As the advisory notes, you do then have to deal with the DoS which the timeout setting is intended to avoid, where N clients all connect and then never disconnect, and they aren't timed-out and forcibly disconnected on the server end any more.)

Thanks for the explanation; I'd skimmed a little too fast and assumed that this was the more traditional "how many attempts can we squeeze in each connection" rather than something at the end. I guess this makes the hardening advice about lowering that time limit kind of unfortunate.

It sounds like at the end of the default 600 seconds is when the race condition occurs. Set no limit, and there is no end

> In our experiments, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 600 seconds (LoginGraceTime), it takes ~1 week on average to obtain a remote root shell.

If you can turn on TCP keepalive for the server connections, you would still have a timeout, even if it's typically 2 hours. Then if someone wants to keep connections open and run you out of sockets and processes, they've got to keep sockets open on their end (but they might run a less expensive userspace tcp)

You can belt and suspenders with an external tool that watches for sshd in pre-auth for your real timeout and kills it or drops the tcp connection [1] (which will make the sshd exit in a more orderly fashion)

[1] https://man.freebsd.org/cgi/man.cgi?query=tcpdrop

Perhaps a more realistic workaround would be simply to make the grace time (or inversely, max connections) long enough that the chances of a successful attack are far too long in the future to be worth attempting.

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

Reply on news.ycombinator.com