[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
