|
Message-ID: <0fedc6a9-9be7-56f3-2ee0-0e07875b86ba@cispa.de> Date: Fri, 6 Oct 2023 12:07:17 +0200 From: Daniel Weber <daniel.weber@...pa.de> To: <oss-security@...ts.openwall.com> CC: <fabian.thomas@...pa.de>, <lukas.gerlach@...pa.de>, <ruiyi.zhang@...pa.de>, Michael Schwarz <michael.schwarz@...pa.de> Subject: Meltdown-US / Meltdown 3a Remaining Leakage Hello, we analyzed the remaining leakage of the "original" Meltdown attack (Meltdown-US) (1) and the variant Meltdown 3a (2). We discovered that the "original" Meltdown attack can be abused to infer the cache state of memory pages that remain mapped despite KPTI. This allows an attacker to monitor interrupt activity. Furthermore, Meltdown 3a can still leak the content of privileged system registers, such as the FS/GS base register or performance counters. ISSUE DESCRIPTION ================= 1) Kernel-page-table isolation (KPTI) does not unmap all memory pages. While the remaining memory pages do not contain confidential data, Meltdown has the side effect of leaking the cache state of the accessed data. We observed that the remaining memory pages contain the KPTI trampoline, the descriptor tables (IDT, GDT, ...), and the task state segment. 2) Intel's microcode updates for Meltdown 3a only prevent the leakage of model-specific registers. Thus, attackers can still leak further system registers. In our analysis, we observed leakage from the time stamp counter register (via rdtsc/rdtscp), the fsbase register (via rdfsbase), the gsbase register (via rdgsbase), and performance counters (via rdpmc). Furthermore, we observed that the instructions rdfsbase, rdgsbase, sldt, and str, may transiently return the value 0. IMPACT ====== 1) By leaking the cache state of an IDT entry, an attacker can observe when an interrupt corresponding to this IDT entry has occurred. Assuming an attacker with local code execution, this can be abused to spy on user activity, such as keystrokes or visited websites. This issue impacts Meltdown-affected CPUs, which rely on the KPTI mitigation. 2) Unprivileged users with local native code execution can read out the above-mentioned system registers. We believe that the only leakage that currently impacts security is the unprivileged access to performance counters, as this leakage enables side-channel attacks, depending on whether and how the performance counters are programmed. To the best of our knowledge, unprivileged reads to the other system registers do not pose a security risk in current implementations. The impacted CPUs are especially Intel CPUs from before 2019, however, the affected system registers vary between CPU models. For AMD, the leakage seems restricted to the FS/GS base register and impacts CPUs ranging from Zen to Zen 3+. MITIGATION ========== Neither Intel nor AMD informed us about plans to rollout further mitigations. 1) Preventing the Meltdown attack from leaking information about the cache state can be achieved by marking the remaining memory pages, e.g., the IDT, as uncacheable. This can be achieved by using a memory-type range register (MTRR) or by modifying the corresponding page-table entries. 2) Preventing the leakage of system registers is not directly possible from a software perspective. Thus, developers should be aware that these contents may be read by unprivileged users and clear affected system registers upon context switches if required. MORE DETAILS ============ 1) - Research Paper: https://publications.cispa.saarland/4011/1/masc_esorics23.pdf - GitHub Repo: https://github.com/cispa/indirect-meltdown 2) - Research Paper: https://publications.cispa.saarland/4010/1/meltdown3a_esorics23.pdf - GitHub Repo: https://github.com/cispa/regcheck With best regards, Daniel, Fabian, Lukas, Ruiyi, Michael
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.