Antonio Larrosa
da2c6cc517
* No changes for askpass, see main package changelog for
details.
- Fix a dbus connection leaked in the logind patch that was
missing a sd_bus_unref call (found by Matthias Gerstner):
* logind_set_tty.patch
- Add a patch that fixes a small memory leak when parsing the
subsystem configuration option:
* fix-memleak-in-process_server_config_line_depth.patch
- Update to openssh 9.8p1:
= Security
* 1) Race condition in sshd(8) (bsc#1226642, CVE-2024-6387).
A critical vulnerability in sshd(8) was present in Portable
OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may
allow arbitrary code execution with root privileges.
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.
OBS-URL: https://build.opensuse.org/package/show/network/openssh?expand=0&rev=272
65 lines
3.2 KiB
Plaintext
65 lines
3.2 KiB
Plaintext
Notes on FIPS mode and OpenSSH
|
|
|
|
---
|
|
|
|
SUSE OpenSSH comes with FIPS 140-2 support, and certain versions have been
|
|
certified as FIPS compliant by NIST. Apart from other things, this standard
|
|
puts restrictions on cryptographic algorithms that may be used.
|
|
|
|
Important notice: FIPS is not only a matter of functionality. If you want to
|
|
claim having a FIPS certified service, you *must* use the certified binaries.
|
|
Even binaries built from the same sources in the same environment and running
|
|
on a certified system, yet from a package lacking the certification, are
|
|
formally not considered to be fulfilling the requirements.
|
|
|
|
The certified binaries (ssh, sshd, sftp-server) perform mandatory selfcheck at
|
|
startup and proceed only when the checks succeed (non-certified binaries may
|
|
skip the check). These checks require the cryptographic hashes contained in the
|
|
openssh-fips subpackage.
|
|
|
|
The FIPS mode for OpenSSH is enabled in two ways - either:
|
|
|
|
1) /proc/sys/crypto/fips_enabled contains a single character '1' - this is a
|
|
system-wide setting controlled bu the fips kernel parameter; or
|
|
|
|
2) the environment variable SSH_FORCE_FIPS - if set (to any value), the
|
|
binaries behave as if they were running on a system in FIPS mode.
|
|
|
|
Since FIPS 140-2 only allows use of certain cryptographic algorithms, both the
|
|
client and server will fail if they are requested to use non-approved
|
|
algorithms while in FIPS mode. This means that working configurations for FIPS
|
|
mode form a proper subset of all working (generic) configurations. Some
|
|
configurations may even prevent the binaries from starting at all.
|
|
|
|
This however should be viewed in the context of FIPS being a security policy
|
|
tool - it is not of much use to run the same system both in FIPS mode and
|
|
outside of it, since that would defeat the main purpose of FIPS having
|
|
guaranteeing standardised minimum restrictions on cryptographic algorithms
|
|
(and thus on the overall security of the system).
|
|
|
|
Unless you specify what cryptographic algorithms you wish to use, both the
|
|
client and server should work out of the box in FIPS mode.
|
|
|
|
For sshd, you can use the `-t` option to check whether the configuration file
|
|
is working. Setting the above mentioned environment variable allows testing of
|
|
behaviour in FIPS mode (checksum files for both OpenSSH and OpenSSL must be
|
|
installed).
|
|
|
|
In addition to cryptographic algorithms restrictions, sshd performs periodic
|
|
PRNG re-seeding. The seed is read from entropy source either /dev/urandom or
|
|
/dev/random. By default, the former is used, unless the environment variable
|
|
SSH_USE_STRONG_RNG is set to a non-zero value or the binary is running in FIPS
|
|
mode. This has two important implications:
|
|
|
|
1) the selected entropy source must be available, i.e. when running in a
|
|
changeroot the device files need to be present there.
|
|
|
|
2) /dev/random is a blocking interface - unless enough randomness is available,
|
|
the process stops until the entropy pool is replenished. Thus on systems where
|
|
a long running processes are expected, one should make sure there is always
|
|
enough entropy for sshd. Sporadically this may also cause sshd to aborted,
|
|
since some versions of OpenSSL (the underlying cryptographic engine) don't
|
|
handle gracefully being interrupted while trying to read entropy from the
|
|
system source.
|
|
|