OpenSSH_7.9p1, OpenSSL 1.1.1k-freebsd 24 Aug 2021 and CVE-2019-16905

13.0-RELEASE-p6

I am dealing with a pci audit and the reason given for a failure is this:
Code:
CVSS Base Score:4.4 AV:L/AC:M/Au:N/C:P/I:P/A:P
CVSS Temporal Score:3.4 E:POC/RL:OF/RC:C
Severity:3
QID:38773
Category:General remote services
CVE ID:CVE-2019-16905
Vendor Reference:OpenSSH 8.1
Bugtraq ID:-
Last Update:2021-10-04 12:29:25.0

THREAT:
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a 
computer network using the SSH protocol.
OpenSSH when compiled with an experimental key type, has a pre-authentication integer overflow if a client or server 
is configured to use a crafted XMSS key. This leads to memory corruption and local code execution because of an error 
in the XMSS key parsing algorithm.
Affected Versions:
OpenSSH 7.7 through 7.9 and 8.x before 8.1
QID Detection Logic:
This unauthenticated detection works by reviewing the version of the OpenSSH service.
IMPACT:
Successful exploitation leads to memory corruption and local code execution on the targeted system.
SOLUTION:
Customers are advised to upgrade to OpenSSH 8.1 or later to remediate these vulnerabilities.

With packages I can see what options were used to build the software. With some software I can query the program itself to discover this. With sshd I cannot check the package because openssh is part of the base system. And I cannot discover any way to ask the software itself.

My questions are:

1. Presuming that OpenSSH on FreeBSD-13.0p6 is not susceptible to this CVE how do I prove it?

2. Absent proof of invenerability, how can I install OpenSSH-8.1 or later to replace the system OpenSSH?
 
Presuming that OpenSSH on FreeBSD-13.0p6 is not susceptible to this CVE how do I prove it?
Look through the security advisories. If it's been patched it will be mentioned there. https://www.freebsd.org/security/advisories/
If it's not patched it may not have been an issue on FreeBSD. That sometimes happens.


Absent proof of invenerability, how can I install OpenSSH-8.1 or later to replace the system OpenSSH?
You install the port/package and make sure that one is started instead. You can't 'replace' anything that's in the base OS. If you build from source you can disable various components, see src.conf(5). This is not possible to do with the binary upgrades (freebsd-update(8)).

A lot of these scanners just look at the version string the daemon produces and base their assumptions on that. But it's quite possible the bug has already been squashed, but the version number remained the same.
 
I checked the advisory page first and found nothing for OpenSSH later than 2017. The release notes at openssh.com state that the 'experimental (xmss) ' key exchange was an optional feature and was only compiled into openssh when specifically requested. I suspect that FreBSD does not include 'experimental' features in software shipped with the base system and so was unlikely to be affected.

I ended up using ssh -Q kex and ssh -Q key to generate a list of supported methods. I trust that such will satisfy the weenies.
 
I suspect that FreBSD does not include 'experimental' features in software shipped with the base system and so was unlikely to be affected.
That is very likely the case here.

The 'problem' with a lot of security/compliance scans is that you can't take their outcome at face value, you always have to interpret the results.
 
It's not yet patched. It's using OpenSSL 7.9p1 and sshkey-xmss.c is at version 1.3 (from OpenSSL 7.8p1)

The Main (current) is updated to OpenSSH v8.7p1

security/openssh-portable
 
When I run ssh -Q kex or ssh -Q kex I do not see anything beginning with XMSS_. From that I infer WITH_XMSS was not defined when the base version of OpenSSH was compiled. Is my inference correct?
 
ssh is the client.
use sshd -dT to see what is supported by the deamon.

I can't find anywhere if WITH_XMSS is included in the build so my guess is that XMSS is not build by default. I also don't see it in the key algorithms from above command.

SirDice
src/secure/ssh.mk file is the file which include the crypto/openssl source files during the build.

13.0.0
 
suport for XMSS is not even the openssh-portable-8.8.p1_1,1 package
i built one with support, made a key
Code:
/usr/local/bin/ssh -v -i .ssh/id_xmss 10.1.1.2 2>/tmp/bug.log
...
/usr/local/bin/ssh -v -i .ssh/id_xmss 10.1.1.1 2>>/tmp/bug.log
...
debug1: Skipping ssh-xmss@openssh.com key .ssh/id_xmss - corresponding algo not in PubkeyAcceptedAlgorithms
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
--
debug1: Skipping ssh-xmss@openssh.com key .ssh/id_xmss - corresponding algo not in PubkeyAcceptedAlgorithms
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
there is no support for XMSS in stock sshd in 12.3 / 13.0
 
The vulnerability is marked as exploitable, but not applicable, as XMSS key support refers to experimental features that are disabled by default (in the portable version, autoconf doesn't even provide an option to enable XMSS).

Problem solved :)
 
Back
Top