Bug 1197760

Summary:	dropbear: RFC 4253 section 8 violation (MATTA-2015-001)
Product:	[Other] Security Response	Reporter:	Vasyl Kaigorodov <vkaigoro>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	buytenh, i, itamar, matt
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-10 20:49:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1197761, 1197762
Bug Blocks:

Description Vasyl Kaigorodov 2015-03-02 14:33:18 UTC

Below issue was reported [1] in Dropbear:
"""
RFC 4253 section 8 describes how the DiffieHellman exchange is done in
SSH... It mandates a few sanity bound-checks (for both the values of
exponents and exponentials) that some implementations are not doing...

MATTA-2015-001 Dropbox
fixed in: https://secure.ucc.asn.au/hg/dropbear/rev/a1e79ffa5862
- The exponential is not checked for all trivial values (it just does
what the RFC mandates, which is clearly not enough!)
- The exponent picked might be a trivial value (this is theoretical more
than anything else assuming the CSPRNG is working). It's a regression
from 0.49
(https://secure.ucc.asn.au/hg/dropbear/diff/00703f1df67a/random.c)

Further details and a full advisory will be published at 
https://www.trustmatta.com/advisories/MATTA-2015-001.txt
https://www.trustmatta.com/advisories/MATTA-2015-002.txt
when the patches are in a released build. Current understanding is
that no third party can take advantage of those bugs unless both the
client and the server are vulnerable AND either side picks a weak
exponent. The likelihood of that happening in practice is almost nil and
the impact limited in any case.

[1]: http://seclists.org/oss-sec/2015/q1/701

External References:

https://www.trustmatta.com/advisories/MATTA-2015-001.txt

Comment 1 Vasyl Kaigorodov 2015-03-02 14:33:53 UTC

Created dropbear tracking bugs for this issue:

Affects: fedora-all [bug 1197761]
Affects: epel-all [bug 1197762]

Comment 2 Matt Johnston 2015-05-21 13:09:31 UTC

I don't think this is a security issue, the PuTTY developers response matches my own thoughts.

http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/diffie-hellman-range-check.html

"With respect to Matta, we do not classify this as a vulnerability: a server sending a value of zero on purpose could just as easily expose the session traffic by other methods anyway (e.g. simply sending a copy of the traffic to whoever it wanted to), and given the range of values from which Diffie-Hellman keys are selected, a server sending the value zero by accident would happen with probability far, far lower than a spontaneous collision in a secure hash function, so if spontaneous hash collision is not considered a vulnerability then neither should this be."