3 ms·

Hang 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, th

Hang 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 ago
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.
pm215 2y ago
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.)
- yjftsjthsd-h 2y ago
  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.
toast0 2y ago
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 https://man.freebsd.org/cgi/man.cgi?query=tcpdrop

Hang 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 ago

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.

pm215 2y ago

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

yjftsjthsd-h 2y ago
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.

toast0 2y ago

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 https://man.freebsd.org/cgi/man.cgi?query=tcpdrop