5 ms·
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 t
by rfmoz 2y ago
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.
- yjftsjthsd-h 2y agoHang on, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html 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?
- sodality2 2y agoIt 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.
- pm215 2y agoThe 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.)
- yjftsjthsd-h 2y agoThanks 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.
- toast0 2y agoIf 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 https://man.freebsd.org/cgi/man.cgi?query=tcpdrop
- ranger_danger 2y agoPerhaps 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.
- dsm9000 2y agowould cold-restarting sshd every hour also make this unlikely / harder to exploit?
- pxx 2y agonot noticeably with the default config? you need to win a race that happens roughly every 120s I guess you could restart every minute...