C implementation of AES is vulnerable to side-channel attacks
Open, NormalPublic

Description

While working on PowerPC support (D490 D491 D492 D493) I noticed that the C implementation of AES is vulnerable to side-channel attacks. (described below)

My patches are not vulnerable to this, but users of libgcrypt on PowerPC *before* my patches are.

slandden created this task.May 27 2019, 9:09 PM
werner added a subscriber: werner.

Can you please give more details and tell whether this is powerpc specific.

slandden closed this task as Invalid.Tue, May 28, 8:12 PM

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

slandden reopened this task as Open.Tue, May 28, 8:14 PM
werner triaged this task as Normal priority.Wed, May 29, 8:27 AM

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.

slandden updated the task description. (Show Details)Thu, May 30, 3:46 PM
slandden updated the task description. (Show Details)Thu, Jun 6, 6:40 PM

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.