Addressing meltdown/spectre in Drupal

greggles's picture

The chromium project blog post about meltdown/spectre has some advice for web applications to increase their security in case a client has not upgraded.

Quoting the 3 main bullet points:

  1. Where possible, prevent cookies from entering the renderer process' memory by using the SameSite and HTTPOnly cookie attributes, and by avoiding reading from document.cookie.
  2. Don’t serve user-specific or sensitive content from URLs that attackers can predict or easily learn. Attackers can load such URLs in their attack pages (e.g. <img src=””/>) to get the sensitive information into the process rendering their page, and can then use out-of-bounds reads to discover the information. Use anti-CSRF tokens and SameSite cookies, or random URLs to mitigate this kind of attack.
  3. Make sure your MIME types are correct and specify a nosniff header for any URLs with user-specific or sensitive content, to get the most out of cross-site document blocking for users who have Site Isolation enabled.

About addressing these in Drupal:

  1. HTTPOnly cookies in Drupal/Apache/Nginx are pretty standard for a while now. The owasp wiki on samesite has some good info. However it appears that PHP has an RFC about samesite support that may not be added until 7.3
  2. Drupal generally uses very predictable urls, so this is a concern. It's possible some kind of module that looks for an extra url param on a list of sensitive urls (e.g. along the lines of what is done in haubergeon) could be helpful.
  3. There's probably some opportunity for more work on mime types and nosniff in the default .htaccess file


Tip 2 removed from Chromium article

TSP's picture

It may be worth noting that Chromium have since removed tip 2: "Don’t serve user-specific or sensitive content from URLs that attackers can predict or easily learn ..." from their article.

A comment was given here:

It seems they removed it

greggles's picture

It seems they removed it because of confusion, not because it is an unnecessary protection for sites that serve sensitive content on well known urls.

That might be. I'm no

TSP's picture

That might be. I'm no security expert. I just noted it was gone.

The confusion was that people believed that pages like this: would be considered insecure (since that URL is the same for everyone logged in to gmail), which is not what this is about, right?

As I understand it the issue is limited to subresources, which I guess is json-documents for example. And that text/html mimetype is not considered to be such a subresource.

Sorry, just trying to learn more about this.

client security vs server side security

mc0e's picture

The key here is to recognise that the suggested measures concern vulnerabilities which might be exploited on the client system, not on the server.

You can only get at information on another Google user's page if you can get that page loaded as the relevant user on a vulnerable system.

Yes, I didn't state this

greggles's picture

Yes, I didn't state this clearly in the original post, but I sort of assume everyone knows "upgrade your kernel and consider other general mitigation strategies" as a first step of protecting Drupal sites on the server side.

The angle I thought would be good to cover in this discussion is "As a Drupal site owner who is concerned about the security of the Drupal app being served to browser, and who knows that those browsers are less likely to upgrade in a timely manner, what protections are appropriate?" Whether a site is an e-commerce site or just used to control sensitive information, having sessions or private data exposed by malicious javascript in a browser tab is pretty scary.

Yeah, having thought through

mpdonadio's picture

Yeah, having thought through how this can be exploited (both ease of distribution and potential ease of implementation), this is rather scary. Site isolation options and mitigations in browsers help, but it would be a good idea to be forward thinking here to prevent these types of things.

I'm wondering if we need to default X-Frame-Options: SAMEORIGIN moving forward, and add this to the security hardening page in the handbook (if it isn't on it already).

I think we need to open a core issue to add a new route option, _sensitive that would append a CRSF token and 403 the page if it it isn't present exist. Could also be handled in contrib.

Drupal 7 and 8 already emit

pwolanin's picture

Drupal 7 and 8 already emit X-Frame-Options: SAMEORIGIN by default

Check Your Server Environment

mgifford's picture

Thanks for starting this @greggles - one point that is pretty obvious but probably should be stated is that server environments, and the kernel specifically need to be updated (and the server needs to be restarted).

If you've got root access to the box & the skills to do this, make sure your servers are up-to-date.

If you don't have root access, I think you can still use tools like this to verify if the new kernel has been applied.

Even simpler, if you've only got shell access, you should be able to check when the server was last reboot. For the kernel updates to be applied, the server needs to be rebooted.
$ uptime -p

That won't tell you if it's been correctly applied, but at least will give you some sense that someone has looked at it.

Hi Greg.Thank you for

ivrh's picture

Hi Greg.

Thank you for sharing your thoughts on Spectre/Meltdown.

Let’s admit that none of these could be mitigated on the Drupal level. Thank you for pointing out to some generic security techniques, though.

Imaging a large-scale deployment of shared accounts, whether these are VPS/containers or good old shared hosting.

As long as a single VPS/account/container gets compromised, attackers could exploit Meltdown and Spectre (there are a few variants of those, some of them are covered by the kernel upgrade, others require BIOS upgrade with the rest are still WIP by the Linux vendors) - access to server memory could be gained and information read (including passwords, credit cards and so on). There is NOTHING you could do on your Drupal side to protect against that.

It's true that the

greggles's picture

It's true that the server-side Operating System and CPU level issues cannot be mitigated by Drupal. That's something that can only be addressed:

  • patching quickly
  • engaging in isolation of your server
  • using SPARC servers :)

Here I hope to problem-solve about the web-related risks to an HTTP client computer with a vulnerable browser, vulnerable client operating system, where the browser is running malicious javascript. For that I believe there are some recommendations (from the document I linked) of what can be done at Drupal and webserver levels.