Breaking News

The Meltdown Over Spectre

Do you know to whom you owe a first debt here at the start of 2018? I do.

I’d like everyone to pause, and in their minds and hearts say thank you to the hundreds of engineers at various hardware, software, and security vendors who spent their holidays working on OS patches, browser patches, cloud roll-outs and distribution of patches for Meltdown and Spectre. (The Q&A section at the bottom of their summary page is excellent.) Thank you to Intel and ARM for their responsible disclosure, great communication, and clear timelines. Kudos to Graz University of Tech and Google and others for finding them.

What do these two threats mean to you, though? What can you do?

At work: Contact your IT team, or if you are on the IT team, get the OS updates pushed out as quickly as possible. Prioritizing this action is important, in an all-hands-on-deck way. This round of patches are critical not to delay, including firmware updates.

Some extra information from the cloud:

  • AWS and Azure are patched at the hypervisor level, which means VMs which are currently in operation there should be ok.
  • Google cloud platform is patched at OS level, so people with VMs there will need to patch their VMs.
  • In general, when using Infrastructure-as-a-Service (IaaS), you will need to update the operating systems of any virtual machines and container base images that you manage.

Do NOT go looking for patches randomly from “helpful” patch sites on the Internet; only use the official patches that arrive via the usual auto notifications of your system, or reach out directly to the vendor website. In general, never trust emails saying, “We scanned your system and found ___.”

It’s possible to use JavaScript to steal stuff from browsers using this bug if your OS is out of date.  Therefore, in addition to installing OS updates as they roll out, please prioritize updating your organization’s browser clients. Firefox, Edge, IE and Chrome all have patches available.

The vast majority of applications do not allow user execution-level access on the server.  In some rare cases, some apps might intentionally give users the ability to execute commands and rely on sandboxing or containerization to keep them from doing harm.  In these rare cases, this bug could allow them to break out or escalate their privilege. There have also not been reported instances of either vulnerability accessing either device storage or databases behind web or mobile applications at this time. However, I do think it is important to be aware of any XSS vulns (which could be used to access saved passwords from the browser’s memory) and Remote Code Executions, because if attackers can run commands on the server, they might be able to chain together an app-level attack using these exploits.

If you have an application-level vulnerability in your DevOps queue from DAST or SAST regarding the insecure storage of logins or passwords, this is an excellent time to prioritize those tickets to prevent that portion of memory from being read by another application using this threat. While Meltdown and Spectre are not vulnerabilities which can be detected via Dynamic or Static Application Security Testing, these are hygiene-type precautions which can help prevent the spread of a successful attack from the server into applications.

General Tip: Remember when building your applications – the least privilege you allow, the more stingy you are with complete data records shared via client or API operation, the fewer opportunities for abuse will exist later. And naturally, we would hope that you do not use the same root login/pw combination on a server as you do on the applications hosted therein. But it never hurts to check, especially in smaller IT organizations where one person fulfills many functions.

Finally, and I’m sure your IT department already says this, but allow me to help reinforce it: If you have an IT-distributed patch system in your organization, let them do their jobs. Just ask in a friendly way when the patches will be available/pushed.