Date: Fri, 29 Jan 2016 16:36:38 +0000 (UTC) From: Mark Felder <feld@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r407484 - head/security/vuxml Message-ID: <201601291636.u0TGacD6063314@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: feld Date: Fri Jan 29 16:36:38 2016 New Revision: 407484 URL: https://svnweb.freebsd.org/changeset/ports/407484 Log: vuxml: Fix openssl entry so `make validate` doesn't throw errors Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Fri Jan 29 16:35:58 2016 (r407483) +++ head/security/vuxml/vuln.xml Fri Jan 29 16:36:38 2016 (r407484) @@ -455,42 +455,42 @@ Notes: <topic>openssl -- multiple vulnerabilities</topic> <affects> <package> - <name>openssl</name> - <range><lt>1.0.2_7</lt></range> + <name>openssl</name> + <range><lt>1.0.2_7</lt></range> </package> <package> - <name>mingw32-openssl</name> - <range><ge>1.0.1</ge><lt>1.0.2f</lt></range> + <name>mingw32-openssl</name> + <range><ge>1.0.1</ge><lt>1.0.2f</lt></range> </package> </affects> <description> <body xmlns="http://www.w3.org/1999/xhtml"> - <p>OpenSSL project reports:</p> - <blockquote cite="https://www.openssl.org/news/secadv/20160128.txt"> - <ol> - <li>Historically OpenSSL only ever generated DH parameters based on "safe" - primes. More recently (in version 1.0.2) support was provided for - generating X9.42 style parameter files such as those required for RFC 5114 - support. The primes used in such files may not be "safe". Where an - application is using DH configured with parameters based on primes that are - not "safe" then an attacker could use this fact to find a peer's private - DH exponent. This attack requires that the attacker complete multiple - handshakes in which the peer uses the same private DH exponent. For example - this could be used to discover a TLS server's private DH exponent if it's - reusing the private DH exponent or it's using a static DH ciphersuite. - OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in - TLS. It is not on by default. If the option is not set then the server - reuses the same private DH exponent for the life of the server process and - would be vulnerable to this attack. It is believed that many popular - applications do set this option and would therefore not be at risk. - (CVE-2016-0701)</li> - <li>A malicious client can negotiate SSLv2 ciphers that have been disabled on - the server and complete SSLv2 handshakes even if all SSLv2 ciphers have - been disabled, provided that the SSLv2 protocol was not also disabled via - SSL_OP_NO_SSLv2. - (CVE-2015-3197)</li> - </ol> - </blockquote> + <p>OpenSSL project reports:</p> + <blockquote cite="https://www.openssl.org/news/secadv/20160128.txt"> + <ol> + <li>Historically OpenSSL only ever generated DH parameters based on "safe" + primes. More recently (in version 1.0.2) support was provided for + generating X9.42 style parameter files such as those required for RFC 5114 + support. The primes used in such files may not be "safe". Where an + application is using DH configured with parameters based on primes that are + not "safe" then an attacker could use this fact to find a peer's private + DH exponent. This attack requires that the attacker complete multiple + handshakes in which the peer uses the same private DH exponent. For example + this could be used to discover a TLS server's private DH exponent if it's + reusing the private DH exponent or it's using a static DH ciphersuite. + OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in + TLS. It is not on by default. If the option is not set then the server + reuses the same private DH exponent for the life of the server process and + would be vulnerable to this attack. It is believed that many popular + applications do set this option and would therefore not be at risk. + (CVE-2016-0701)</li> + <li>A malicious client can negotiate SSLv2 ciphers that have been disabled on + the server and complete SSLv2 handshakes even if all SSLv2 ciphers have + been disabled, provided that the SSLv2 protocol was not also disabled via + SSL_OP_NO_SSLv2. + (CVE-2015-3197)</li> + </ol> + </blockquote> </body> </description> <references>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601291636.u0TGacD6063314>