Bug 770

Summary: Small subgroup attack
Product: unbound Reporter: Luke Valenta <luke.valenta>
Component: serverAssignee: unbound team <unbound-team>
Severity: major CC: cathya, des, wouter
Priority: P5    
Version: unspecified   
Hardware: All   
OS: All   

Description Luke Valenta 2016-05-26 21:15:49 CEST
In https://github.com/jedisct1/unbound/blob/master/daemon/remote.c, the get_dh1024 function returns a hard-coded 1024-bit DSA group used for Diffie-Hellman key exchange. The command used to generate get_dh1024 is "openssl dhparam -dsaparam -C 1024" according to a comment in the source code.

There are two things to note:

+ First, using DSA or other non-"safe" primes for Diffie-Hellman is not recommended. A better command to generate DH parameters is "openssl dhparam -C 2048". Note that I've also increased the key size from 1024 bits to 2048 bits, since a 1024-bit key size is considered insecure (https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf).

+ Second, due to a bug in the version of OpenSSL used to generate the current hard-coded parameters, the subgroup order q for the generated DSA group is not included in the DH parameters (i.e., dh->q is not set). This prevents the underlying OpenSSL library from checking that a received DH key exchange value is in the correct subgroup, leaving Unbound open to a potential small subgroup attack.

To fix this vulnerability, the following should be done:

+ replace the get_dh1024 function and all references to it in https://github.com/jedisct1/unbound/blob/master/daemon/remote.c with get_dh2048 as generated by "openssl dhparam -C 2048". This command might take a couple minutes to run.
Comment 1 Wouter Wijngaards 2016-05-27 08:50:55 CEST
Hi Luke,

Thank you for the bugreport and the details.

Fixed this as you suggest, and committed for future release.

This code is only used when a named unix pipe is used on localhost, and thus is not remotely exploitable.  But good security is important there too.

Best regards, Wouter
Comment 2 Dag-Erling Smørgrav 2016-07-01 15:29:18 CEST
This is not a security issue.  The control socket is intended to be protected only by Unix file and directory permissions.  The only reason why the connection is encrypted is that there is no clean separation in the code and adding support for an unencrypted control connection would have required a huge amount of refactoring.