| title | excerpt | updated |
|---|---|---|
How to mitigate the Inception vulnerability |
Learn about the CVE-2023-20569/Inception/Return Address Security (RAS)/Speculative Return Stack Overflow (SRSO) vulnerability and its impacts on OVHcloud products |
2023-08-22 |
This page may be updated regularly.
Edit 2023-08-22 14:00 CEST: Update iPXE section to mention limitations (UEFI boot is required, Ryzen processors are not supported)
On August 8th 2023, AMD has issued a security bulletin disclosing a vulnerability in its recent computer processor microarchitecture. Named "Return Address Security (RAS)" by AMD, the vulnerability is also known as "Inception".
Labelled CVE-2023-20569 and rated by AMD as Medium, the issue allows an attacker to potentially access sensitive information processed by the CPU in specific circumstances.
The issue affects all software running on the affected processors, including virtual machines, sandboxes, containers, and processes. Exploitation software has been released by the researchers and shows how this vulnerability could be leveraged in a multi-user context.
At least the following architectures are vulnerable:
- Zen (Family 23)
- Zen+ (Family 23)
- Zen2 (Family 23)
- Zen3 (Family 25)
- Zen4 (Family 25)
In response to that event, we immediately reviewed the security bulletin and technical information and determined the following potential impact on our products:
| Range of products | Products | Impact |
|---|---|---|
| Public Cloud | All products | Not impacted |
| Hosted Private Cloud | All products | Not impacted |
| Web Hosting & Domains | All products | Not impacted |
| Bare Metal Cloud | ADVANCE-3 Gen 2 ADVANCE-4 ADVANCE-4 Gen 2 ADVANCE-5 ADVANCE-5 Gen 2 ADVANCE-LE GAME-1 GAME-2 GAME-LE HGR-HCI-4 HGR-HCI-5 HGR-HCI-6 HGR-SDS-2 INFRA-2-LE INFRA-3 INFRA-3-SE RISE-4 RISE-GAME-1 RISE-GAME-2 RISE-LE-2 SCALE-1 SCALE-2 SCALE-3 SCALE-7 SYS-6 SYS-7 |
Potentially impacted Check below how you can mitigate the vulnerability |
| Bare Metal Cloud | Other commercial ranges of dedicated servers | Not impacted |
The first action is to check if your server is impacted by the vulnerability. You might use the following tool (Linux-only) developed by our team and that has been updated to take in consideration CVE-2023-20569:
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
# sh spectre-meltdown-checker.sh --variant inception --explain- If the tool says
NOT VULNERABLEthen you are already safe and no further action is needed.
{.thumbnail}
- If the tool says
VULNERABLEyou should then evaluate your exposure to the threat.
{.thumbnail}
It is necessary to determine if the server context allows to run code from an untrusted origin.
If the server is used to provide services to untrusted end-users that can execute code (VPS, Container, shared hosting, etc.), or is used as a desktop in the cloud browsing the Web (hence possibly running 3rd party JavaScript payloads), then your server might be at risk.
If the server is used only by trusted users and/or does not allow to run untrusted code, the risk of exploitation is probably quite low.
Please note however that this vulnerability might allow an attacker to gain extra privilege in a chained attack, it could be used for persistence or lateral movement in a complex kill chain.
Based on this evaluation, you should determine the emergency to trigger a mitigation and choose the most appropriate one.
These architectures do not require a microcode update since the IBPB feature introduced in 2018 to mitigate Spectre v2 already works fine to flush branch type predictions from the branch predictor.
The new updates of the Kernel provide mitigations for this vulnerability at the Kernel level.
To mitigate this vulnerability, you can also disable the SMT feature (Simultaneous MultiThreading) by changing the boot parameters.
Warning
This mitigation may have a serious impact on the overall performance of the system.
These architectures require a kernel update and a microcode update to be fully protected.
The new updates of the Kernel provide mitigations for this vulnerability at the Kernel level. According to the Kernel contributors these mitigations may significantly lower the risk of exploiting the vulnerability. The Kernel mitigations would be enough even without the microcode update.
This solution will trigger the update of the processor microcode through an operating system update (the linux-firmware package for instance). You might do it as soon your OS editor or community distribute the updated package. This method is dependent on your distribution or Operating System editor and will only work if the appropriate microcode has been provided by AMD.
OVHcloud teams are working to implement transparent solutions that will ensure the patched microcode is updated in a transparent way for our customers. Those solutions will be deployed progressively on our servers using the solution detailed below.
The microcode update may be loaded by the bootloader when the standard OVHcloud netboot is used by customers (the most common configuration). The feature is available so rebooting the server through the OVHcloud Control Panel will cause it to load the updated microcode before booting to disk, which will mitigate the vulnerability. However, if you are booting on disk without using the OVHcloud netboot system, the mitigation will not be applied and you should consider relying on the Operating-System-level mitigation.
[!primary]
Reminder: This solution requires a public interface with a public IP and UEFI boot to work. It is not compatible with legacy boot servers.
Warning
AMD only provides updated microcodes for EPYC processors, this solution is not available for Ryzen processors.
The UEFI firmware update may update the CPU microcode at boot. UEFI firmware updates including the patched microcode will likely be made available by motherboard manufacturers within the next months.
Once available, OVHcloud will include this patched microcode on the UEFI for any new delivered server. Customers will then be able to request an UEFI firmware update by contacting the support.
No official benchmark has been releaseda by AMD so far. Nevertheless a benchmark has been done by Phoronix comparing the different Kernel mitigations in different context. You can find it here: https://www.phoronix.com/review/amd-inception-benchmarks/.
Our technical and support teams are working to ensure the risk is lowered for each of our customers impacted by the vulnerability. We mostly focus on:
- Informing impacted customers to ensure they take the risk into account in their operations and implement mitigation appropriately.
- Developing and integrating updates in our automation to cover the risk in a transparent way for our customers.
- Security watch of the vulnerability exploitation in the wild to define the appropriate extra mitigations we can implement to protect our customer infrastructures.
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
https://comsec.ethz.ch/research/microarch/inception/
https://github.com/speed47/spectre-meltdown-checker/
https://github.com/comsec-group/inception
https://github.com/torvalds/linux/commit/138bcddb86d8a4f842e4ed6f0585abc9b1a764ff
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20569