Upgrade to OpenSSH 9.8p1 (when available, soon)

[v1gnesh]

9.8p1 will be available soon via zopencommunity/opensshport#12

This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function
that is directly called by sshd's SIGALRM handler. In other words:

- OpenSSH < 4.4p1 is vulnerable to this signal handler race condition,
  if not backport-patched against CVE-2006-5051, or not patched against
  CVE-2008-4109, which was an incorrect fix for CVE-2006-5051;

- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable to this signal handler race
  condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added
  to sigdie() by the patch for CVE-2006-5051 transformed this unsafe
  function into a safe _exit(1) call);

- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again to this signal handler
  race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was
  accidentally removed from sigdie()).

Source: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

@KeplerBoyce @IgorTodorovskiIBM - for testing the new vuln apparatus :)

[IgorTodorovskiIBM]

If anyone is wondering, the latest z/OS port of OpenSSH is 8.4p1, which is not affected by this vulnerability - https://www.ibm.com/docs/en/zos/3.1.0?topic=zbed-zos-openssh.

I'll need to look into this further, but it may not affect non-glibc systems:

Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon.

Exploitation on non-glibc systems is conceivable but has not been
examined. Systems that lack ASLR or users of downstream Linux
distributions that have modified OpenSSH to disable per-connection
ASLR re-randomisation (yes - this is a thing, no - we don't
understand why) may potentially have an easier path to exploitation.
OpenBSD is not vulnerable.