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.

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).

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”.