Bug 1135368 - (CVE-2019-11840) VUL-0: CVE-2019-11840: snapd: Keystream loop in amd64 assembly when overflowing 32-bit counter
(CVE-2019-11840)
VUL-0: CVE-2019-11840: snapd: Keystream loop in amd64 assembly when overflowi...
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Security
Leap 42.3
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Zygmunt Krynicki
Security Team bot
https://smash.suse.de/issue/232462/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-05-16 14:15 UTC by Alexandros Toptsoglou
Modified: 2019-05-17 05:26 UTC (History)
0 users

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 Alexandros Toptsoglou 2019-05-16 14:15:56 UTC
CVE-2019-11840

A flaw was found in  the amd64 implementation of the golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

Upstream patch:

https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc057239113d

References:

https://groups.google.com/forum/#!msg/golang-announce/tjyNcJxb2vQ/n0NRBziSCAAJ

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1691529
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-11840
http://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11840.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11840
https://github.com/golang/go/issues/30965
https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc057239113d
https://groups.google.com/forum/#!msg/golang-announce/tjyNcJxb2vQ/n0NRBziSCAAJ
Comment 1 Alexandros Toptsoglou 2019-05-16 14:16:49 UTC
It seems that that snapd bundles salsa20
Comment 2 Alexandros Toptsoglou 2019-05-16 21:27:54 UTC
see also bsc#1135416
Comment 3 Zygmunt Krynicki 2019-05-17 05:26:36 UTC
The following text contains an analysis of the the impact of the CVE on snapd. The analysis was performed by Jamie Strandboge.

 jdstrand> snapd contains an embedded copy of golang-go.crypto with the
  affected code
 jdstrand> snapd doesn't import/use the salsa code directly, but does vendor
  golang-gopkg-macaroon.v1, which imports golang.org/x/crypto/nacl/secretbox
  which does import salsa and contains the affected salsa2020XORKeyStream.
  snapd uses secretbox.Open() and secretbox.Seal(), both of which use
  salsa.XORKeyStream() (which wraps salsa2020XORKeyStream) via the internal
  decrypt() and encrypt() functions, respectively. In macaroon.v1, encrypt() is
  only used via AddThirdPartyCaveat() and decrypt() via Verify().
  .
  overlord/auth/auth.go in snapd uses Verify() in CheckMacaroon(),
  daemon/api.go uses CheckMacaroon() in UserFromRequest(), which is called by
  ServeHTTP(), the service used to process snap commands from the local system
  to the local snapd. This CVE does not affect decrypt() operations.
  .
  AddThirdPartyCaveat() is only used in unit tests, but not in the binaries of
  snapd builds.
  .
  For snapd, ignoring since only encryption operations (ie, secretbox.Seal())
  are affected with regard to loss of confidentiality/predictability and this
  function is only ever (ultimately) called via the snapd unit tests.


The embedded copy of the affected libraries will be refreshed in the next scheduled release (2.39.1).