Cyber Attack: Understanding The Meltdown Fault And How To Protect It

The computer security flaws Meltdown and Specter, affecting the Intel processors (and AMD for Specter), marked the beginning of the year 2018. An immense amount of machines are vulnerable to these flaws, which are exceptional in that they affect the material layer of our information systems. Regardless of the operating system or software: If a computer or server is equipped with Intel processors, it may be compromised.

Cyberattack MeltdownIn this article, we will focus on Meltdown, which is easier to exploit for pirates than Specter … even if it is far from trivial! The risk: by exploiting the flaw, an attacker can have access to all the random access memory (RAM) of the targeted machine, and thus recover sensitive information such as login credentials. Let’s understand how this computer threat works, using speculative execution, and how Net4All protected its customers.

Processor and process: contextualization

To be able to read all the RAM of a machine vulnerable to the Meltdown Fault, an attacker must have access, virtual or physical, to one of the open processes on this machine. This process benefits from one or more dedicated processors (CPUs), and a space of RAM that is allocated to it. This space is divided into several virtual addresses, each to access a data.

The operation of the process requires exchanges between the memory and the processor, which retrieves the data needed to process the requests. This communication is provided by the “kernel”, a vital part of any operating system linking the hardware and software components of the machine.

This is why, within the memory space allocated to the process, there are two “subspaces”: the “userland” or userspace, and the “kernel and” or kernel space. This kernel space, the interface between the processors and the user spaces, contains a “mapping” (mapping) of all the physical memory of the machine, thus of all the user spaces of all the processes. The process user space, on the other hand, contains a mapping of the kernel space, even if it can not access it because of the sensitivity of the information that it contains.

IT attack: Exploitation of the Meltdown Fault

Phase 1: preparation

The hacker thus benefits from his userspace and will exploit it to gain access to the kernel space. For that, it will start by creating the equivalent of an array (a “probe array” or network of probes) within the user space. All the cells of the array (the “pages” of the “probe array”) are independent, and each corresponds to an identifier.

Phase 2: access to the kernel

Second, the attacker will try to guess a secret value X, stored at the N address of the kernel space. He will create and execute a sequence of instructions, which aims to:

recover the value X in the kernel space, at the virtual address N

access, in the table prepared beforehand, to the box whose identifier corresponds to the value X

After the first step, the value X is put in a register of the internal memory of the processor, inaccessible to the attacker, like the results of all the treatments. In parallel, the virtual address N is cached, also within the processor, in order to access it faster the next time.

To know the value X, the attacker therefore needs another lever, corresponding to the second objective: the processor recovers the value X in its internal memory, then finds the box with the same value, and accesses the address corresponding virtual, which will be named C. As earlier, this virtual address is cached in the internal memory of the processor.

So, once the code is executed:

the value X in a register

N and C addresses in the cache

Security breach: Meltdown and speculative execution

Access to the kernel is prohibited, the processor should stop the processing of these instructions from the first line of code, and thus complete the hacking attempt … Indeed, in case of a forbidden request, the processor throws an “exception” that stop the treatment.

Now, the current processors benefit from a particular feature, which allows gaining in performance: speculative execution, or “out-of-order execution”. It allows the processor to process the instructions it receives, but in a different order than the one requested by the process. Thus, the processor can optimize the exploitation of its resources by guessing the next instructions to be processed, and getting ahead of its work! If he has guessed right, he will send the result of his treatments, stored in the meantime in his internal register, to the memory of the process, and he will continue his actions of treatment.

It is this time gained in the processing of instructions that will allow the hacker to access the kernel space and recover the data. Indeed, the thrown exception takes longer to arrive than it takes to process the sequence of instructions sent by the attacker. The processor will, therefore, process the entire sequence of instructions, then realize then that he should not have done.

This case, where the processor realizes that he was wrong, is not exceptional and does not pose any particular problem. The processor simply removes from its registry the results of instructions it should not have processed and resumes the next steps. However, as we have seen, once the code is executed, not only the results are stored in a register, but also the virtual addresses of the memory spaces are cached … and they are not deleted! This is where the flaw lies, and that’s what the attacker will exploit in the third phase of the hacker attack.

Phase 3: retrieval of information

For now, all that the attacker knows is the N address he himself chose, and which virtual address corresponds to which box of the table created in the userspace. He must now retrieve information obtained in previous phases to finalize his cyber attack.

For this, the hacker uses what is called a side-channel attack. The most mentioned in the context of Meltdown is called “Flush + Reload”, we will not detail it under penalty of extending the size of this article. It allows him to measure the access time to an address of the userspace. The attacker iterates this attack on all the addresses corresponding to the boxes of its table. Access to one of the boxes (in our case, the one stored at address C) is faster than the others: it is the one that was cached during the previous phase.

However, the attacker knows that the address C has been hidden the page of the table whose identifier is equal to the value X sought. He only has to do the correspondence between the address and his table to find the identifier, and that’s how he finally knows the value X!

Access to all memory via iteration

As we saw in the context presentation of this cyber attack, the kernel space contains a map of all the physical memory of the machine. This means that by repeating phases 2 and 3 of the attack on all kernel space addresses, the attacker can, after a while, recover all the data stored on the machine … In this case, even the randomization of the memory space distribution does not mitigate the fault!

IT Protection: Escape from Meltdown

This very worrying situation, which opens a door to cybercrime, has greatly mobilized our teams. For Microsoft servers, we follow the process of updating the publisher. For Linux servers, however, an action plan was quickly put in place, even before the patches were released, to protect the machines as quickly as possible.

Thus, when the KAISER patch was available on Tuesday, January 9, our teams were able to immediately test its implementation and then embark on updating and restarting the machines of our customers. On Monday the 15th, almost all of the Linux farm was protected.

This hotfix greatly improves the isolation between the two memory spaces, removing the kernel space card from the user space, except in a few specific cases. The userspace therefore simply no longer has the physical possibility to access the kernel space.

The downside is a pretty alarmist information that said the application of this fix results in a performance down to 30% … Indeed, with this structural change, the processor can no longer use its cache system, and therefore, it must regularly recalculate data that it had previously stored. However, we have recorded at Net4All a drop of 1 to 2% performance with cyber protection in place, a very light sacrifice to protect against the Meltdown fault! Note, thanks to this low rate and the fact that we practice very little over-allocation of resources, we were able to cash the surcharge without any incident.

Leave a Reply

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