Using Osquery to Verify MDS/Zombieload Mitigations on MacOS

As a part of a pretty crazy week (Microsoft/RDS, Apple/Mojave/High Sierra, Adobe Acrobat/Flash Player) when it comes to security updates, some new speculative execution vulnerabilities were disclosed and fixed.

These vulnerabilities consist of those called RIDL, Fallout and Zombieload, though using CVE’s to track them is perhaps easier, as most of these names sound like awesome video games.

• CVE-2018-12126
• CVE-2018-12127
• CVE-2018-12130
• CVE-2019-11091

These vulnerabilities are similar to Meltdown/Spectre as they exploit speculative execution and caching features of CPUs, meant to improve performance. Like Meltdown/Spectre, long term fixes will require changes to CPUs, but mitigations by the operating system are possible. For a great summary of how these vulnerabilities are exploited, see Ars Technica.

Their mitigations also share some similarities. There are various levels of mitigation, and the complete deactivation of hyper-threading is the most secure but most performance impacting solution. I wrote in the past about how osquery can be used to ensure systems are properly protected against Meltdown/Spectre. On the Windows side, the story is similar - depending on your OS type and version (client / server, 2016 vs 2019), some mitigations are enabled by default and some are not. The matrix is relatively complex, but you can easily monitor the registry keys using the registry table, as well as leverage the kva_speculative_info table as mentioned in the Meltdown article.

MDS on Mac is not too different, in the sense that the latest macOS update (10.14.5) must be installed, which you can easily verify with the os_version table.

On macOS, a “full mitigation” for MDS is also provided by Apple. This mode impacts performance heavily, as it basically disables Hyper-Threading, and as such, is not enabled by default. In specific environments, based on risk, if you have deemed it necessary to ensure the threat is fully mitigated, you can confirm the configuration has been applied properly by using the nvram table.

Specifically, the value for boot-args should be cwae=2 and SMTDisable should be set to %01.

These values are typically not configured at all, so you need to ensure a value is returned and that it is the right one. For those environments, we highly recommend enabling a firmware password, as that prevents anyone without the password from resetting nvram.

While this specific mitigation should not be used by everyone, due to the low risk and high performance impact, it shows, just like Meltdown/Spectre on Windows Server, that some vulnerabilities require more than patch deployment.

Osquery is uniquely positioned to help you track security configurations over time thanks to its standardized schema and cross-platform capabilities making it useful for much more than simple system hardening!

Related osquery resources:

• Osquery: What it is, how it works, and how to use it