CPU Security VulnerabilitiesIn this blog post, we examine the recent revelations about CPU security vulnerabilities.

The beginning of the new year also brings to light fresh and new CPU security vulnerabilities. Today’s big offenders originate on the hardware side – more specifically, the CPU. The reported hardware kernel bugs allow for direct access to data held in the computer/server’s memory, which in turn might leak sensitive data. Some of the most popular CPUs affected by these bugs are Intel, AMD and ARM.

The most important thing to know is that this vulnerability is not exploitable remotely, and requires that someone execute the malicious code locally. However, take extra precaution when running in virtualized environments (see below for more information).

A full overview (including a technical, in-depth explanation) can be found here: https://meltdownattack.com/.

These three CVEs refer to the issues:

Although the problems originate in hardware, you can mitigate the security issues by using updated operating system kernel versions. Patches specific to database servers such as Percona Server for MySQL, Percona Server for MongoDB, Percona XtraDB Cluster and others are unlikely.

Fixes in Various Operating Systems

Fixes and patches are available for Windows and MacOS. Not all major Linux distributions at the time of this post have released patches (though this is expected to evolve rapidly):

CPU Security VulnerabilitiesSecurity Impact

As mentioned above, this vulnerability is not exploitable remotely. It requires malicious code to be executed locally. An attacker must have either obtained unprivileged shell access or be able to load malicious code through other applications to be able to access memory from other processes (including MySQL’s memory).

To potentially exploit the vulnerability through MySQL, an attacker theoretically needs to gain access to a MySQL user account that has SUPER privileges. The attacker could then load UDF functions that contain the malicious code in order to access memory from the MySQL Server and other processes.
In MongoDB a similar behavior would need to use eval().

Cloud Providers, Virtualization and Containers

Some hypervisors are affected by this as they might access memory from other virtual machines. Containers are affected as well, as they can share the same kernel space.

More information (source):

Performance Impact

As a general rule, Percona always recommends installing the latest security patches. In this case, however, the decision to immediately apply the patch is complicated by the reported performance impact after doing so. These patches might affect database performance!

RedHat mentions the expected impact to be measurable, and Phoronix.com saw a noticeable hit for both PostgreSQL and Redis.

At this time, Percona does not have conclusive results on how much performance impact you might expect on your databases. We’re working on getting some benchmarks results published shortly. Check back soon!

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
fipar

Great post!

As someone very far from being a security expert, I have a question about this: “The most important thing to know is that this vulnerability is not exploitable remotely, and requires that someone execute the malicious code locally. ”
Is that accurate? I have read about javascript POCs for exploits. Couldn’t a malicious web site (or a malicious ad on an otherwise ok website) exploit this too? After all, a web browser is a way to conveniently grant remote access to a third party to your local computer.

I’m asking because my personal level of concern about this slowly moved from “This would only matter on shared hosting/cloud environments” to “we really are all affected”.

David Busby

Hi Fipar,

The statement is accurate, what you are describing is attack escalation.

e.g. let’s take for example a website which has a R.C.E (Remote Code Execution) vulnerability.

Could the attacker once they have exploited the vulnerability go on to use Spectre / Meltdown ?

Almost certainly, the key here is that at this point the adversary has chained together vulnerabilities in order to gain the required access to leverage spectre / meltdown.

This is something I have spoken about when demonstrating exploitation of a MySQL installation which was network isolated such that you could not directly access the MySQL instance.

[Adversary] – RCE -> [WEB] -> [MySQL]

The video is available here: https://www.youtube.com/watch?v=e29kbX-rx0s (5:28, No audio apologies this is a backup video for the talk) this demonstrates chaining existing vulnerabilities together in order to:

1. Exploit the webserver using a known vulnerability (0:50)
2. Use the webserver as a pivot to gain access to the MySQL server (which is firewall isolated, preventing direct access to the service – 2:10)
3. Use existing credentials to access the MySQL service (User has FILE, CREATE_ROUTINE, SUPER, etc… grants 2:47).
4. Stage the UDF binary (3:28)
4. Exploit existing file permissions misconfiguration to write the .so to the filesystem (3:54)
5. Exploit the excess permissions of the MySQL user to CREATE ROUTINE (4:01)
6. Use bash TCP functionality to establish a reverse shell on the MySQL system (4:55)

So from this example multiple vulnerabilities are chained to attain the overall exploitation of the systems, as I end the video sure I do not have root _BUT_ I could look to exploit the system as I have shell access and escalate my privileges from the MySQL / HTTPD user.

With meltdown and spectre there is no known direct exploitation via remote means, it however most certainly can be chained along with other vulnerabilities to gain private data from the target system, and is one extra tool in an adversaries arsenal, honestly it’s by far more effective to escalate privileges to root and then get access to “all the things” (in the absence of Mandatory Access Control which prevents root having access to “all the things”).

If you (or anyone reading) would like to “play at home” with the exploit chain I demo in the linked video the code is available on Github here: https://github.com/Oneiroi/talks/tree/master/Security_and_why_you_need_to_review_yours

The takeaway here is the following:

Spectre & Meltdown are not directly remotely exploitable.
Spectre & Meltdown can be used where the adversary already has remote access to the target system (this includes RCE, and is not limited to a traditional shell access of course).

fipar

Hello David, thanks for the reply! It’s all clear to me know.

My level of concern here is maintained because the surface of attack for RCE seems too wide due to the implicit trust we have in software we use (see https://news.ycombinator.com/item?id=16087024 for example), but that still does not make it a remote exploit.

If anything, I hope one outcome of this is that we review how trust is handled in our dependencies systems, as my feel is that with these attacks the biggest threat comes from that. At the very least, this hopefully prompts people to stop disabling gpg checks in yum just ‘for convenience’ …

These attacks make ‘Reflections on Trusting Trust’ be as relevant now as ever.