Bug 1197760 - dropbear: RFC 4253 section 8 violation (MATTA-2015-001)
Summary: dropbear: RFC 4253 section 8 violation (MATTA-2015-001)
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1197761 1197762
TreeView+ depends on / blocked
Reported: 2015-03-02 14:33 UTC by Vasyl Kaigorodov
Modified: 2021-02-17 05:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-06-10 20:49:24 UTC

Attachments (Terms of Use)

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

Further details and a full advisory will be published at 
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:


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.


"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."

Note You need to log in before you can comment on or make changes to this bug.