Bug 1396943

Summary:	Insecure 1023 and 1535 bit moduli sizes in /etc/ssh/moduli (Logjam)
Product:	Red Hat Enterprise Linux 7	Reporter:	Karsten Weiss <knweiss>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.3	CC:	mgrepl, mjtrangoni, nmavrogi, szidek
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-12-07 13:05:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Karsten Weiss 2016-11-21 09:07:11 UTC

Description of problem:

OpenSSH in RHEL 7.3 still ships with 1023 and 1535 bit moduli in
/etc/ssh/moduli used in Diffie-Hellman Group Exchange (should be
at least 2047 bit).

Isn't this is considered insecure?

Compare e.g. the Logjam attack recommendation:

https://weakdh.org/sysadmin.html#openssh

Or https://stribika.github.io/2015/01/04/secure-secure-shell.html

Version-Release number of selected component (if applicable):

# rpm -qf /etc/ssh/moduli
openssh-6.6.1p1-31.el7.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.3 (Maipo)

How reproducible:

Always.

Steps to Reproduce:
1. egrep -w '1023|1535' /etc/ssh/moduli | wc -l
2.
3.

Actual results:

# egrep -w '1023|1535' /etc/ssh/moduli | wc -l
86
$ head -n 2 /etc/ssh/moduli
#    $OpenBSD: moduli,v 1.8 2012/08/29 05:06:54 dtucker Exp $
# Time Type Tests Tries Size Generator Modulus
$ grep -w 1023 /etc/ssh/moduli | head -n 1
20120821044040 2 6 100 1023 5 D9277DAA27DB131C03B108D41A76B4DA8ACEECCCAE73D2E48CEDAAA70B09EF9F04FB020DCF36C51B8E485B26FABE0337E24232BE4F4E693548310244937433FB1A5758195DC73B84ADEF8237472C46747D79DC0A2CF8A57CE8DBD8F466A20F8551E7B1B824B2E4987A8816D9BC0741C2798F3EBAD3ADEBCC78FCE6A770E2EC9F

Expected results:

Moduli in /etc/ssh/moduli should be at least 2047 bit in size.

Here's the current openssh-portable git repo:

$ pwd
[...]/openssh-portable.git
$ egrep -w '1023|1535' moduli | wc -l
0
$ head -n 1 moduli
#    $OpenBSD: moduli,v 1.18 2016/08/11 01:42:11 dtucker Exp $

Removal dates:
* 2016-03-01: Upstream removed 1535 bit moduli 
* 2015-05-28: Upstream removed 1023 bit moduli (released in OpenSSH 6.9)

Additional info:

This issue also applies to RHEL 5 and 6.

[
From the moduli(5) man page:

"When performing Diffie-Hellman Group Exchange, sshd(8) first estimates the size of the modulus required to produce enough Diffie-Hellman output to sufficiently key the selected symmetric cipher. sshd(8) then randomly selects a modulus from /etc/ssh/moduli that best meets the size requirement."
]

Please consider updating OpenSSH in RHEL 7.4.

Comment 2 Jakub Jelen 2016-11-21 15:00:42 UTC

Well, saying that 1023 bits is not enough today is questionable. Based on the table on the top of the page 8 [1], the times are sill quite large to believe it can be true (millions core-years to pre-computation, 30 core-days for a single connection is not much real-time decryption).

But for future, bumping the values as upstream does is preferable and planned. Thank you for the report.

For the RHEL6 and RHEL5, it is probably too late to make it default, but feel free to contact your Red Hat support if you consider this important.

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Comment 3 Karsten Weiss 2016-11-21 17:15:53 UTC

Thanks for you reply.

FWIW there are also the current NIST recommendations: See chapter 5 of http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf.
Quote: "SP 800-56A DH and MQV schemes using finite fields:
The use of the finite field schemes in SP 800-56A is acceptable if
len(p) >= 2048 and len(q) >= 224. Otherwise, their use is disallowed."

Also, http://eprint.iacr.org/2016/995.pdf recommends "safe-primes of documented provenance of at least 2048 bits".

The paper https://eprint.iacr.org/2016/961.pdf concludes with this lesson:
"Our results are yet another reminder that 1024-bit primes should be considered insecure for the security of cryptosystems based on the hardness of discrete logarithms. The discrete logarithm computation for our backdoored prime was only feasible because of the 1024-bit size, and the most effective protection against any backdoor of this type has always been to use key sizes for which any computation is infeasible. NIST recommended transitioning away from 1024-bit key sizes for DSA, RSA, and Diffie-Hellman in 2010 [6]. Unfortunately, such key sizes remain in wide use in practice."

[6] E. Barker and A. Roginsky. Transitions: Recommendation for transitioning the use of cryptographic algorithms and key lengths. Technical report, National Institute of Standards and Technology, 2011.
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf

I'm no cryptographer but IMHO there's no good argument for *keeping* the 1023 bits moduli.

Comment 4 Karsten Weiss 2016-11-28 09:25:29 UTC

Also, from a security best practice point of view it wouldn't hurt to generate an all new /etc/ssh/moduli file for each Red Hat Linux minor release i.e. rotating *all* generators and moduli with each minor release instead of using the same values for 10+ years of RH Enterprise support.

Comment 5 Jakub Jelen 2017-03-08 13:05:48 UTC

We do not want to change the default in mid-release this much. Especially without any simple way to revert for legacy clients/servers connections as upstream did it.

Also other libraries are not following there yet. We are aware of this problem and plan to resolve this system-wide.

For hardening, it is very easy to remove the short moduli from /etc/ssh/moduli in post-install scripts/configuration management.