OpenSSL Updates

announcements

This security announcement details three OpenSSL CVEs:

Oxide software embeds the OpenSSL libraries for use in TLS processing and related cryptographic processing. We do not believe that these vulnerabilities impact Oxide software. The next software release will contain an update to OpenSSL.

Revision History
RevisionDate (YYYYMMDD)Changes

1.0

20230808

Initial Release

Impacted Products

Oxide Software Release v1.0.1. While the Oxide CLI embeds OpenSSL, it does not currently utilize affected functionality.

Impact

CVE’s 2023-3817 and 2023-3466 relate to similar paths where by validating Diffie-Helman keys through OpenSSL’s DH_check() function could lead to extended processing time. This could manifest as a denial of service. CVE 2023-2975 relates to issues with the AES-SIV algorithm that could allow empty data not to be properly authenticated. AES-SIV is not currently used in Oxide products.

Action Required

Please ensure to update to the next regularly scheduled Oxide release.

For guest virtual machines, please check with your OS provider to ensure that the latest version of OpenSSL (3.1.2, 3.0.10, 1.1.1v, 1.02zi) is installed.

Mitigations

There are no mitigations available at this time for this.

Technical Background

For full details, please see the related OpenSSL write ups in the Additional Information section.

Aug 8 2023

Zenbleed

announcements

This security announcement details an AMD side channel attack that impacts AMD Zen 2 processors. Oxide products are not impacted by this security vulnerability. This notice provides additional context on this side channel attack that relies upon speculative execution in the processor and is provided as additional background to aid in understanding this and related issues. AMD calls this AMD-SB-7008 Cross-Process Information Leak.

Revision History
RevisionDate (YYYYMMDD)Changes

1.0

20230808

Initial Release

Impacted Products

No Oxide products are impacted by this issue. No Oxide computer can boot or operate with an AMD Zen 2 processor installed, nor will that be offered in the future. This vulnerability impacts AMD Zen 2 based CPUs which include the following:

  • AMD EPYC 7XX2 Rome (Family 17h, model 31h)

  • AMD Threadripper 3000 series Castle Peak (Family 17h, model 31h)

  • AMD Ryzen 3000 Series Matisse

  • AMD Ryzen 4000 Series Renoir (family 17h, model 60h)

  • AMD Ryzen 5000 Series Lucienne (family 17h, model 68h)

  • AMD Ryzen 7020 Series Mendocino (Family 17h, model a0h)

Impact

There is no impact from this issue for Oxide products. The following only applies to non-Oxide systems.

This vulnerability allows the leaking of the upper 128-bits of the FPU registers, which depending on the specifics of an operating system, can contain sensitive information as many implementations of cryptography algorithms or even basic memory copying leverage these registers. This allows a process running on a core to see information left behind by a prior process (regardless of whether that process is inside a virtual machine or not).

Action Required

There is no action required for Oxide products.

For other products and systems, please follow your vendor’s documentation for determining if a Zen 2 CPU is installed is installed. If you have a Zen 2 based CPU listed above installed in a non-Oxide computer, please check that system’s OS or BIOS vendor to see if a CPU microcode update is available.

Mitigations

There are no mitigations available for Oxide systems as Oxide products are not impacted by this vulnerability.

Technical Background

For a more detailed explanation, please see the write up from Tavis Ormandy who discovered this vulnerability.

AMD CPUs support the AVX family of instructions. These instructions extend the CPU’s vector registers to 256-bits often referred to as the YMM registers. These registers shadow the original 128-bit XMM registers. That is, %xmm0[127:0] is the same a %ymm0[127:0]. When switching between the different classes of instructions, it is often required to zero the upper 128-bits of a YMM register. This is most often done with an explicit x86 instruction called vzeroupper which zeros all upper bits of the vector registers.

While x86 registers are explicitly named in the assembler, internally the CPU is much more complex and the common names of registers points to a register file . These hardware resources are shared between both hardware threads within the core and is not statically partitioned. When the vzeroupper instruction is used, rather than actually zero the underlying data, it will often just set a flag indicating that this is the case in the hardware.

The problem occurs when the CPU speculatively executes a vzeroupper and then aborts that due to a misprediction. This can lead the register contents to then contain the prior contents prior to setting the zero flag. This allows another user to read the prior data that was put into the register by either hardware thread.

Additional Information

The following URLs provide additional information about this vulnerability.

Aug 8 2023