Bug 931600 - (CVE-2015-4000) VUL-0: CVE-2015-4000: The Logjam Attack / weakdh.org
(CVE-2015-4000)
VUL-0: CVE-2015-4000: The Logjam Attack / weakdh.org
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Major
: ---
Assigned To: Security Team bot
Security Team bot
CVSSv2:SUSE:CVE-2015-4000:7.3:(AV:N/A...
: DSLA_REQUIRED, DSLA_SOLUTION_PROVIDED
Depends on: 938905 938906 931698 932483 935856 937202 937766 938432 938913 938945 955589
Blocks: 931845 932026 934789 935033 935540
  Show dependency treegraph
 
Reported: 2015-05-20 08:08 UTC by Alexander Bergmann
Modified: 2022-02-13 11:07 UTC (History)
14 users (show)

See Also:
Found By: ---
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 Alexander Bergmann 2015-05-20 08:08:33 UTC
Tracker Bug: "The Logjam Attack"

It came to our attention that there seams to be a flaw in the TLS protocol, so that connections can be tricked into using weak encryption.

Published information can be found at the following website:

    https://weakdh.org/

We are currently evaluation which SUSE products are affected by this problem and will update this bug accordingly.
Comment 1 Marcus Meissner 2015-05-20 08:58:11 UTC
As far as I understand:

Server side:
- do not offer DH primes bits(p) < 1024 anymore at all.
- (optionally plan for 1024 obsoletion too)
- allow selecting and generating user DH primes
- documentation of these can be done (is linked on above side)


Client side:
- MUST hard refuse all DH primes bits(p) < 1024


FWIW, NIST 800-131A allows DH 2048 bitlength p since January 2014 only. (and bitlength of q 224 or 256 bits.
Comment 2 Marcus Meissner 2015-05-20 18:32:07 UTC
From Mitre:

CVE-2015-4000 has been assigned to this vulnerability in the TLS
protocol that was disclosed in section 3.2 of the
https://weakdh.org/imperfect-forward-secrecy.pdf paper:

   "a flaw in the way TLS composes DHE and DHE_EXPORT. When a
   server selects DHE_EXPORT for a handshake, it proceeds by
   issuing a signed ServerKeyExchange message containing a
   512-bit p512, but the structure of this message is identical
   to the message sent during standard DHE ciphersuites.
   Critically, the signed portion of the server's message fails
   to include any indication of the specific ciphersuite that
   the server has chosen."

(This is the TLS protocol problem associated with the Logjam attack.)

There are some other vulnerabilities mentioned on the weakdh.org web
site that can have individual CVE IDs for each affected codebase, if
any researcher (or a vendor) identifies a specific available codebase
(i.e., not one organization's in-house code). Also, there are security
issues mentioned on the weakdh.org web site that can have individual
CVE IDs for each affected codebase, if the author of the code requires
a CVE ID for announcing the issue to customers. Finally, there are
other issues mentioned on the weakdh.org web site that should not have
CVE IDs, but for which it is possible that someone is considering
using CVE IDs. Here are some examples of this distinction.


section 3.5 - "some servers in our scans used Java's DSA primes as p,
but mistakenly used the DSA group order q in the place of the
generator g ... This substitution of q for g is likely due to a
usability problem: the canonical ASN.1 representation of
Diffie-Hellman key exchange parameters (coming from PKCS#3) is a
sequence (p, g), while that of DSA parameters (coming from PKIX) is
(p, q, g); we conjecture that the confusion between these formats led
to a simple programming error."

[ So, for example, if someone identifies a specific open-source
product that has this programming error, a CVE ID can be assigned,
even if the vendor's perspective is unknown. ]


section 3.2 footnote - "Safari allowed groups as small as 16 bits"

[ It seems that there's a high probability that this was unintentional
behavior, and thus a CVE ID from Apple may be forthcoming. ]



section 3 - "for both normal and export-grade Diffie-Hellman, the vast
majority of servers use a handful of common groups"

[ This is a type of issue that typically does not have a CVE ID
because it is associated with the concept of third-party configuration
data. Although we don't currently have complete documentation on what
"third-party configuration data" means within CVE, the important
points in this situation are:

1. Use of a common group obtained from a third party was not a
choice that would have been anticipated to be unreasonable.

2. Avoiding use of a common group is not really equivalent to
correcting a software mistake; it could typically involve improving a
software product by adding new functionality or documentation, such as
adding a call to "openssl dhparam" at installation time.

3. Existence of a common group across different customers' deployments
of a product is not independently exploitable; there is no attack that
depends exclusively on knowing the group used by a victim.

For example, it seems likely and appropriate that multiple vendors
from the https://weakdh.org/sysadmin.html Common Server Products list,
and a large number of other vendors, will adjust their own
documentation (or installation process) to incorporate the general
concept of "generate a new, unique Diffie-Hellman group." However, we
don't feel that there should be CVE IDs to, in effect, track each
vendor's progress toward this, or to criticize a vendor's choices
(e.g., putting it only in documentation, with no new installation
functionality). Instead, it can probably be treated as another
important security improvement that becomes available to persons who
pick up newer versions. ]

- -- 
CVE assignment team, MITRE CVE Numbering Authority
Comment 4 kolA flash 2015-05-20 19:23:26 UTC
/etc/ssl/openssl.cnf from package openssl-1.0.1k-2.20.1.x86_64 still has:
  default_bits		= 1024

Looks like this low value comes from openssl upstream. But at least Debian 7 (openssl-1.0.1e) changed this value to 2048.

I think openSUSE/SUSE should changes this to
  default_bits		= 4096
(or at least 2048)

https://weakdh.org/imperfect-forward-secrecy.pdf
| We provide new estimates for the computational resources necessary
| to compute discrete logarithms in groups of these sizes, concluding
| that 768-bit groups are within range of academic teams, and
| 1024-bit groups may plausibly be within range of state-level
| attackers.
Comment 5 Marcus Meissner 2015-05-20 20:34:20 UTC
This default_bits setting is read only by the openssl commandline "req" subcommand and does not influence the library.

The fixes are in other places. for openssl look at bug 931698.
Comment 6 Swamp Workflow Management 2015-05-20 22:00:14 UTC
bugbot adjusting priority
Comment 7 Andreas Stieger 2015-05-21 07:56:46 UTC
statement from openSSL:
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
Comment 8 Marcus Meissner 2015-05-21 11:30:49 UTC
I forked off some tracker bugs:

Status:
- openssl: bug 931698

  openssl will be adjusted to reject < 768 bit DH parameters

- apache2: bug 931723

  apache2 SLE12 is ok and can take admin supplied dhparams
  apache2 SLE11 does only have 1024bit DH params, not admin supplyable currently.

  workaround: use apache2-mod_nss on SLE11

- openvpn: Allows specification of DH parameters in config file.

  We should document that 2048bit params are generated and how.
Comment 16 Swamp Workflow Management 2015-07-22 13:09:50 UTC
openSUSE-SU-2015:1277-1: An update that solves 16 vulnerabilities and has one errata is now available.

Category: security (important)
Bug References: 912015,912018,912292,912293,912296,919648,920236,922496,922499,922500,931600,934487,934489,934491,934493,934494,937891
CVE References: CVE-2014-3570,CVE-2014-3572,CVE-2014-8176,CVE-2014-8275,CVE-2015-0205,CVE-2015-0206,CVE-2015-0209,CVE-2015-0286,CVE-2015-0287,CVE-2015-0288,CVE-2015-0289,CVE-2015-1788,CVE-2015-1789,CVE-2015-1790,CVE-2015-1792,CVE-2015-4000
Sources used:
openSUSE 13.2 (src):    libressl-2.2.1-2.3.1