(added cve to ref) |
|||
Line 41: | Line 41: | ||
== References == | == References == | ||
* Lipp, Moritz, et al. "[https://arxiv.org/abs/1801.01207 Meltdown]." arXiv preprint arXiv:1801.01207 (2018). | * Lipp, Moritz, et al. "[https://arxiv.org/abs/1801.01207 Meltdown]." arXiv preprint arXiv:1801.01207 (2018). | ||
+ | * "CVE-2017-5753", https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753 | ||
[[category:cve]] | [[category:cve]] |
Revision as of 16:40, 26 January 2018
CVE-2017-5754 (Meltdown, Variant 3, Rogue Data Cache Load) is a microprocessor vulnerability that allows an attacker to overcome all memory isolation mechanisms offered by the microprocessor by causing it to speculatively execute code out-of-order that loads inaccessible information which end up changing the cache state of the microarchitecture, thereby leaking information through side-channel timing analysis.
Overview
Rogue Data Cache Load leverages the speculative execution out-of-order behavior of the microprocessor in order to cause some code to expose more information than intended. Specifically, Meltdown breaks the basic memory isolation assumptions that's used by the operating system to manage the virtual memory of each process.
Consider the following code.
char val = *(char *)0xAAAAA;
When executed, this line will likely cause a segmentation fault due an access restriction violation. Meltdown demonstrated that while the fault is being handled by the operating system (in an elevated supervisor mode), the microprocessor can continue to execute subsequent code out-of-order under the assumption that this is the right path. More-so, Meltdown demonstrated that this code can be executed as supervisor, thereby reading potentially memory it should not have access to. A carefully crafted piece of code by an attacker can be used in a way similar to Spectre Variant 1 to leak any kernel space memory.
Example
Consider the following (simplified) code.
char probeTable[256] = {0}; /* op 1 */
/* ... */
char val = *(char *)0xAAAAA; /* op 2 */
char temp = probeTable[val]; /* op 3 */
Consider what happens when operation 2 is executed. The microprocessor will realize that this is an access violation and the exception will result in a context switch to the operating system in order to handle the fault. When this happens, the microprocessor will also speculatively start to execute operation 3 out of order. Meltdown demonstrated that this code can be executed as supervisor, thereby reading potentially memory it should not have access to.
Since probeTable
is uncached, the code that executed cause a cache miss, resulting the microprocessor going and grabbing the value from main memory. Meanwhile, the operating system will likely kill the process the for the invalid memory access.
Although the code has been terminated and the architectural state of the machine has been restored, the state of the microarchitecture has changed. If an attacker is running a second process (e.g., a parent process), then probeTable[]
can be used in conjunction with a side-channel analysis timing attack, to determine the value of byte
in probeTable[byte]
. Since probeTable
was initially uncached, the only element in probeTable
that is cached is the secrete byte stored in *(char *)0xAAAAA
.
This method can then be used repeatedly to read a larger part of memory.
Proof-of-Concept
- Meltdown Proof-of-Concept - https://github.com/IAIK/meltdown
See also
- CVE-2017-5753, Spectre, Variant 1
- CVE-2017-5715, Spectre, Variant 2
References
- Lipp, Moritz, et al. "Meltdown." arXiv preprint arXiv:1801.01207 (2018).
- "CVE-2017-5753", https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753