In this blog, Derk Tegeler (Security Officer at iWelcome) shares his thoughts and possible mitigation measures for two major vulnerabilities that hit the news earlier this month: Meltdown and Spectre. Just a heads-up: this article contains technical security information.
First, an introduction to the wonderful world of software
Before going more in-depth, allow me a moment to explain a little about software. When developing software, we intend it to run on a ‘machine’ offering memory (or: RAM), storage and processing capabilities. This ‘machine’ is expected to safely run our software next to software developed by others. Hence, we make a reasonable assumption that ‘our’ little piece of memory is secure (in terms of confidentiality, integrity and availability) and that our data cannot be read or modified by others.
Let’s call this software – when running on a ‘machine’ – a process. A process is an instance of the software we have developed that runs concurrently with other processes through timesharing, on one single CPU processor at a time. Each process is started by a master process called a kernel (also regarded as the heart of an operating system), which allocates resources to it, as well as a security context.
In modern (cloud) computing environments, this ‘machine’ is often a virtual one, sharing processing time and memory with other virtual machines (VMs). This means that a computer offers an environment for several kernels to run concurrently (often referred to as hypervisor).
Now that we know the basics about processes, processors, memory and security expectations, let’s introduce Meltdown and Spectre, two scary vulnerabilities shattering the security expectations we have just explained.
A word of caution: the context of the remainder of this article is iWelcome and its production environment; we do not make any claims outside of our own domain.
The implications and mitigation measures for Meltdown
Meltdown is a hardware vulnerability affecting a wide range of processors. This vulnerability allows processes to read regions of memory (RAM) that should not be accessible to.
To the best of our knowledge, hypervisors do not allow cross virtual machine (VM) exposure so VMs running on the same hardware cannot access the memory of one another. However, just to make sure this is and remains the case, we have deployed measures preventing this (amongst others by deploying patched hypervisors).
Software running on production hosts is tightly controlled, preventing a Meltdown exploit from exposing or divulging data.
Meltdown is easier to mitigate when privilege separation is considered weak which is something we have always done. Access control does not rely solely on privilege separation measures, but rather expects this to be fundamentally broken. In other words: at iWelcome we have already taken measures preventing and mitigating the effects of confidentiality loss of memory regions.
This does not absolve us from implementing published patches, fixes and counter measures as soon as these become available. And despite the fact that the boundary of the virtual machine cannot be crossed, one might also consider fixes at the hypervisor’s kernel level. This is something we have done, just to be sure.
The implications and mitigation measures for Spectre
The Spectre vulnerability is a weakness in how memory is accessed within a single process. Unlike Meltdown, it does not allow for one process reading memory regions from another.
This leaves the browser – the end point used by millions of users: the number one place where we input information…
Most browsers have been fixed and patched by now, so the Spectre vulnerability is only a real danger to people not updating software. This however is a huge problem on its own, certainly when considering mobile devices where software updates are critical and often badly implemented.
From the web developer’s perspective, even if you have taken measures to prevent the downloading and execution of malicious code, you simply can’t prevent others from behaving badly, in another browser tab.
As you browse the web, leaving multiple tabs open, your browsers have hundreds of lines of code in memory, potentially exploiting the Spectre vulnerability, exposing whatever is in the browsers memory (note: a browser is a process, like any other software instance).
From an end-user’s perspective, the Spectre vulnerability shows that the browser is a crucial security element. We recommend that laptops and other computing equipment are kept as up-to-date as possible, and to quickly install fixes and safeguards when these become available. Even more importantly, we should invest in educating users in general: which online behaviour is safe or unsafe, when and why.
And, to conclude, a quick message to our cherished web developers: browsers are constantly adding security features, such as process isolation per domain and content-security-policies, to name a few interesting ones. This is good, both for our unsuspecting and digitally challenged users and for security in general. But do not rely on it too much. Send only what the users need and treat any packet coming from a browser as suspect and hostile. You can soften your paranoid stance once you’ve cleared, cleansed and checked the data.
That’s it from our side. We hope it was worth the read!
Security Officer at iWelcome
With more than two decades of experience in technology fields where security and scalable infrastructures are recurring themes, Derk brings seasoned expertise in governance, assurance, and compliance, embedding security into architecture and infrastructure, design and coding processes and cryptography.
Feel free to repost this blog on your website or social channels! But when you do so, please be so kind to mention the source and give us a notice via firstname.lastname@example.org.