Bug 1055837 - (CVE-2017-0379) VUL-0: CVE-2017-0379: libgcrypt: side channel attack on Curve25519
(CVE-2017-0379)
VUL-0: CVE-2017-0379: libgcrypt: side channel attack on Curve25519
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/191034/
CVSSv3:SUSE:CVE-2017-0379:3.7:(AV:N/A...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-27 20:02 UTC by Marcus Meissner
Modified: 2019-05-29 07:57 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2017-08-27 20:02:21 UTC
ecc: Add input validation for X25519.

* cipher/ecc.c (ecc_decrypt_raw): Add input validation.
* mpi/ec.c (ec_p_init): Use scratch buffer for bad points.
(_gcry_mpi_ec_bad_point): New.

--

Following is the paper describing the attack:

    May the Fourth Be With You: A Microarchitectural Side Channel Attack
    on Real-World Applications of Curve25519
    by Daniel Genkin, Luke Valenta, and Yuval Yarom

In the current implementation, we do output checking and it results an
error for those bad points.  However, when attacked, the computation
will done with leak of private key, even it will results errors.  To
mitigate leak, we added input validation.

Note that we only list bad points with MSB=0.  By X25519, MSB is
always cleared.

In future, we should implement constant-time field computation.  Then,
this input validation could be removed, if performance is important
and we are sure for no leak.

CVE-id: CVE-2017-0379
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
(cherry picked from commit bf76acbf0da6b0f245e491bec12c0f0a1b5be7c9)
Comment 1 Marcus Meissner 2017-08-28 07:14:57 UTC
our code in ecc_decrypt_raw in SLE12:Update looks different, but we might just be missing some checks.
Comment 2 Andreas Stieger 2017-08-31 14:19:12 UTC
https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000414.html

Noteworthy changes in version 1.8.1 (2017-08-27)
================================================

   - Mitigate a local side-channel attack on Curve25519 dubbed "May
     the Fourth be With You".  [CVE-2017-0379]
[...]
Noteworthy changes in version 1.7.9 (2017-08-27)
================================================

   - Mitigate a local side-channel attack on Curve25519 dubbed "May
     the Fourth be With You".  [CVE-2017-0379]
Comment 3 Andreas Stieger 2017-08-31 14:20:06 UTC
https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000414.html

Comments on the vulnerability
=============================

Details on this attack can be found in the paper

  May the Fourth Be With You: A Microarchitectural Side Channel Attack
  on Real-World Applications of Curve25519
  by Daniel Genkin, Luke Valenta, and Yuval Yarom

  https://eprint.iacr.org/2017/806.

Note that this side-channel attack requires that the attacker can run
arbitrary software on the hardware where the private Curve25519
encryption key is used.  In GnuPG a Curve25519 key used for encryption
is shown as "cv25519".  Signature keys based on Curve25519 (in GnuPG
"ed25519") are not affected.

Allowing other users to run software on a machine with private keys
should be considered a full security compromise of that machine, anyway.
Thus in practice there are easier ways to access the private keys than
to mount this side-channel attack.  However, on boxes with virtual
machines this attack may be used by one VM to steal private keys from
another VM.
Comment 4 Vítězslav Čížek 2017-11-20 16:28:38 UTC
Curve25519 was introduced in libgcrypt 1.7.0.
(https://lists.gnu.org/archive/html/info-gnu/2016-04/msg00005.html)

This affected only Factory before update to 1.8.1.
Reassigning to the security-team.
Comment 5 Andreas Stieger 2017-11-20 16:32:58 UTC
done