Let me add that we are also currently working on an article on configuration hardening for Torizon OS. It is certainly not advisable in most cases to leave the SSH server enabled on a production device.
The Torizon remote access feature was not affected by CVE-2024-39894, even though it uses openssh’s sshd as the underlying server. This is because when you open a remote session, the service is spun up on-demand, with a very restricted configuration generated only once the session creation metadata from the server has been validated. Password authentication is explicitly disabled, as is PAM authentication. The only form of authorization accepted is public key authentication, and therefore this vulnerability is not exploitable because it is a password keystroke timing attack.
In addition to Bruno’s excellent advice above, I would point out that we generate a full SPDX SBOM with every release, so your security team can ingest that into vulnerability monitoring tooling. The CVE scan data is generated at build time, so new vulnerabilities that didn’t exist at build time can’t be included; the SBOM allows you to keep up with emerging threats based on the actual packages built (and signed via our in-toto attestations) instead of having to rely on composition analysis tools.
And finally, I’ll tease something that we’ll be showing next month at Embedded World and making available to existing Torizon customers in early access shortly thereafter: my team and I are working on vulnerability analysis tooling, and will be making a CycloneDX SBOM with embedded Vulnerability Exchange (VEX) information available for future release versions of Torizon OS. VEX is a standard format for describing relevant information about security vulnerabilities in software, and by providing this information to our customers we intend to greatly reduce the burden of vulnerability management, as required by the Cyber Resilience Act and various other recent and emerging cybersecurity regulations. As a small preview, I can share with you an excerpt of the VEX information we will publish related to the openssh package:
{
"id": "CVE-2007-2768",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-2768"
},
"analysis": {
"state": "not_affected",
"detail": "STATE: not-applicable-config\nJUSTIFICATION: This CVE is specific to OpenSSH with the pam opie which we don't build/use here.\n"
},
"affects": [
{
"ref": "urn:cdx:d8e59a0e-4999-49b8-9b31-e9722cb4019f/1#pkg-openssh-9.6p1"
}
]
},
{
"id": "CVE-2014-9278",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9278"
},
"analysis": {
"state": "not_affected",
"detail": "STATE: not-applicable-platform\nJUSTIFICATION: This CVE is specific to OpenSSH server, as used in Fedora and Red Hat Enterprise Linux 7 and when running in a Kerberos environment\n"
},
"affects": [
{
"ref": "urn:cdx:d8e59a0e-4999-49b8-9b31-e9722cb4019f/1#pkg-openssh-9.6p1"
}
]
},
{
"id": "CVE-2008-3844",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-3844"
},
"analysis": {
"state": "not_affected",
"detail": "STATE: not-applicable-platform\nJUSTIFICATION: Only applies to some distributed RHEL binaries.\n"
},
"affects": [
{
"ref": "urn:cdx:d8e59a0e-4999-49b8-9b31-e9722cb4019f/1#pkg-openssh-9.6p1"
}
]
},
{
"id": "CVE-2023-51767",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51767"
},
"analysis": {
"state": "not_affected",
"detail": "STATE: upstream-wontfix\nJUSTIFICATION: It was demonstrated on modified sshd and does not exist in upstream openssh https://bugzilla.mindrot.org/show_bug.cgi?id=3656#c1.\n"
},
"affects": [
{
"ref": "urn:cdx:d8e59a0e-4999-49b8-9b31-e9722cb4019f/1#pkg-openssh-9.6p1"
}
]
},
{
"id": "CVE-2024-39894",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39894"
},
"analysis": {
"state": "resolved_with_pedigree",
"detail": "STATE: resolved-with-pedigree\nJUSTIFICATION: Fixed by Patches: ['CVE-2024-39894.patch']\n"
},
"affects": [
{
"ref": "urn:cdx:d8e59a0e-4999-49b8-9b31-e9722cb4019f/1#pkg-openssh-9.6p1"
}
]
}
As you can see, the last item on the list indicates that the vulnerability has been resolved, and lists the specific evidence justifying that. Since it’s in a standardized, machine-readable format, this can be imported into vulnerability management tooling so that you can see at a glance whether a particular vulnerability has already been analyzed. You will also be able to reference the pedigree of the resolution via the pedigree field for the package in the components portion of the SBOM.
I’m really excited to get this released. It’s not easy, and we’re having to write new tooling and processes for this in many cases. But we believe that it’s getting more and more important to have transparency and accountability in software supply chains, and that responsible suppliers in that chain shouldn’t leave all the work of vulnerability management to end users.
