I've been looking into getting a VPS to run an OpenVPN server on and a few other things. I've been speaking to a hosting company and they have sent me this screenshot to show they are protected against all currently known exploits on their hypervisors:


However, protecting against known implementations of the exploits might not necessarily mean I am fully protected. Is there still a chance VPS data can be compromised today, or is it becoming a thing of the past? Should I be concerned or is it a lot less likely than I think?


1 Answer 1


The current state of Spectre, Meltdown, L1TF, SRDBS, etc. on most platforms, with all patches applied and default mitigations enabled, is that attacks across security boundaries (e.g. cross-core, cross-VM, cross-process) are either impossible or highly impractical. On virtualised hosts, an up-to-date virtualisation platform (e.g. ESXi, Xen) should apply strong mitigations to cross-VM attacks as long as CPU microcode updates have been performed.

When it comes to checking the state of these issues on a host, this sentence is really the crux of it:

However, protecting against known implementations of the exploits might not necessarily mean I am fully protected.

Your VPS provider appears to be running RedHat's own detection script. This is probably fine, but I can't find a public copy of that script, and RedHat require a subscription to download it. As such, it may just be checking for kernel patches.

I would recommend asking your hosting provider to run spectre-meltdown-checker, which checks the status of the CPU in a platform-agnostic way, and looks for OS patches and mitigations. The methods are publicly documented. Having good results from both the RedHat script and the open source script is about as much assurance as you could hope for.

More generally speaking, you should be mostly protected against known CPU side-channel attacks on an up-to-date version of RedHat. The OS will apply mitigations by default and the VPS provider would have to turn them off to leave you vulnerable - something that's not in their interests to do as a virtualised hosting provider.

An attacker who executes untrusted code in the context of a process may still be able to exploit some of these attacks, to varying degrees, but they will generally only be able to recover information from that process. The microcode updates offer some protection against cross-core attacks, and the OS patches mitigate the cross-process side of the vulnerability by being careful to flush caches during context switches across security boundaries. In a server environment there are few (if any) cases where untrusted code executes in the same process as trusted code, and if an attacker can gain unrestricted arbitrary code execution in the context of a process on the server they aren't likely to bother with a side-channel attack.

The main scenario that people worry about with Meltdown and Spectre, outside of the VPS space, is browsers, since you have multiple documents from different origins running untrusted code (e.g. JavaScript) alongside each other, often in the same process. If an attacker can exploit a side-channel attack from JavaScript (which is entirely possible, and has been done) they can use it to get access to process memory. If multiple documents from different origins are loaded into that same execution context, they can access resources from those other documents and violate the same-origin policy (SOP). This is why SharedArrayBuffer is restricted behind COOP/COEP - it is highly useful as a primitive for exploiting these issues, so browsers require that any resource that wants access to that primitive must be isolated in its own process.

All in all, I wouldn't worry too much. Your average attackers don't tend to use this stuff, and even the more advanced ones (which you generally shouldn't worry about unless you're an MSP, NGO, CNI, TLA, gas & oil company, or global comms provider) don't bother unless there's a major reason to. There are only a few odd scenarios where side-channel attacks like this are relevant against a server instead of a client browser.

The TL;DR - try to ensure that patches are applied, but don't focus time and attention on this stuff to the detriment of more likely attack vectors such as outdated packages, webapp bugs, config issues, information exposure, poor quality firewall rules, etc.

  • Great, I'll ask them if they can run the script. What qualifies as a 'good' result? Should I expect everything to pass as green?
    – Letal1s
    Oct 15, 2021 at 9:45
  • Yup, pretty much.
    – Polynomial
    Oct 15, 2021 at 23:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .