Special Update on the Spectre/Meltdown Intel Chipset Vulnerability


Axis Of Easy Special Update


 

In this issue:

  • The Intel chipset bug
  • What and who is affected
  • What to do about it

 

The Intel chipset bug

A security research team discovered two separate vulnerabilities in Intel chips that exploit weaknesses in the isolation between the operating system and the application layer in one case, and between different applications in the other. Dubbed “Spectre” and “Meltdown”, these weaknesses affect pretty well all Intel chipsets and if exploited, can expose sensitive data on the device (such as passwords) and cannot be detected via traditional means.

Also: https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html

The security researchers reported their findings to Intel June 1, 2017. Intel’s CEO initiated a plan to sell $24 million USD of his stock on Oct 30, 2017, ahead of the public disclosure, (which of course, is completely unrelated to this.)

 

What and who is affected

Pretty much everybody. This means you.

It is unclear to me at this point if AMD bugs are affected or not. I have read that this problem is not confined to Intel chips, Intel’s statement on this mentions that they are collaborating with AMD and other chipset makers on a fix. I don’t know whether this means “we’re getting advice from people who aren’t affected” or if that means “we’re all affected and figuring out what to do”.

My original read on this was that local access (i.e. a unix shell or command prompt) was required to exploit the kernel. This was still bad news for cloud platforms (AWS, Digital Ocean, et al) and web hosts that allow shell access. The attack would, at least theoretically, put sensitive data across all virtual machines on a shared hardware instance at risk. Serious enough.

But then I was made aware that the Spectre paper mentions that the Spectre vulnerability is attackable via javascript:

“Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.”

So far there have been no known exploits sighted in the wild, however given that a successful attack would be harder to detect than most, we should be doing what we can to reduce our attack surfaces sooner than later.

 

What to do about it

Security Response professional Chris Mills is collating a comprehensive list of vendors, platforms, browsers, patches on his blog here.

Some selected crib notes:

  • Firefox: make sure to run latest version (above 57) as per their advisory.
  • Chrome: go to “chrome://flags/#enable-site-per-process” in your browser and make sure “Strict Site Isolation” is enabled.
  • Developers/Webmasters: The Google chrome notes on this also includes guidelines on how to best handle cookies, mime-types and to use CRSF tokens.
  • Cloud operators: should be applying kernel patches, one big drawback about all this is that apparently, the patches to this can slow chip performance by up to 30%. A serious hit in that department.

Again, follow the progress of vendor published info as this plays out and take appropriate actions.

 

#AxisOfEasy resumes normal programming next week.

I’d wish you all a “Happy New Year” but that may be off the table at this point.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in the know of what's up around the 'net weekly: #AxisOfEasy

x