Meltdown-US / Meltdown 3a Remaining Leakage

[Daniel Weber <daniel.weber () cispa de>]

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