Description
Revisions and Commits
Related Objects
Event Timeline
I do not have a PoC (or much interest in making one, I have too many more important things to do), but I believe this to be correct, based heavily on PPC knowledge of Nicolas König <koenigni@student.ethz.ch> . This attack also applies to AMD, Intel, and ARM.
The encrypt and decrypt tables are stored in the .rodata section of the ELF. If two processes map the same file they get differn't virtual addresses (because of PIC), but the same physical address. CPU caches work with physical addresses, after the MMU translates the address.[1]
While L3 cache is not vulnerable to this attack on PPC, because it isn't unified and not inclusive, L2 (shared between code pairs) and L1 (shared between SMT threads) are, and processes can evict these at will (and do not need to even rely on preemption to evict the AES table). If they evict the table (which they have a handle to via loading the dynamic library) while the other process is doing AES, then they can do the flush and reload attack.[2]
The fix is make the physical address unavailable to other processes by having the prefetch functions copy the table to a global static variable, that will not be shared with other processes.
[1] PPC has 64 slots (D-ERAT) that are not MMU translated, but that is only 4096bytes, the size of the table, and code also has to be in that cache too, so it doesn't protect from this attack.
[2] https://eprint.iacr.org/2016/596.pdf
Thanks for taking the time to describe this attack vector. We will need to study this closer to balance such a change with other side effects of this.
This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904
Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.
I assigned the CVE, but yes it needs more facts.
El dom., 23 de jun. de 2019 10:45, werner (Werner Koch) <
noreply@dev.gnupg.org> escribió:
werner added a comment.
Andreas, I wonder on which grounds you assigned a CVE for this claimed
side-channel attack. The mentioned paper is about an old RSA side-channel
and not on AES. I would like to see more facts than the reference to a guy
who knows PPC pretty well.*TASK DETAIL*
https://dev.gnupg.org/T4541*EMAIL PREFERENCES*
https://dev.gnupg.org/settings/panel/emailpreferences/*To: *werner
*Cc: *ametzler1, werner, slandden, pmgdeb, Rafixmod, srgblnchtrn, gp_ast,jukivili, lumag
This is an automated email from the GnuPG development hub. If you have
registered in the past at https://bugs.gnupg.org/ your account was
migrated automatically. You can visit https://dev.gnupg.org/ to set a new
password and update your email preferences.
Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.
Folks, I was just wondering if I could get an update on where we are with this bug. It seems we aren't sure if it's a real issue or not. What's the latest thought?
As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.