openbsd, branch libressl-v2.1.8 A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v2.1.8 2015-10-15T02:23:26+00:00 pull up fixes for leak and overrun 2015-10-15T02:23:26+00:00 tedu 2015-10-15T02:23:26+00:00 urn:sha1:1f0c7b9086ce1dc80bced5fa35412dcbdde99fa0 MFC: Fix several defects from OpenSSL. 2015-06-11T16:09:23+00:00 jsing 2015-06-11T16:09:23+00:00 urn:sha1:7ef74dad52fbca9122cd668d868d85d0e0762a1a These include: CVE-2015-1788 - Malformed ECParameters causes infinite loop CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time CVE-2015-1792 - CMS verify infinite loop with unknown hash function Fix several crash causing defects from OpenSSL. 2015-03-19T14:01:20+00:00 tedu 2015-03-19T14:01:20+00:00 urn:sha1:5880eaad897594cd2996545010f7b301fa948230 These include: CVE-2015-0209 - Use After Free following d2i_ECPrivatekey error CVE-2015-0286 - Segmentation fault in ASN1_TYPE_cmp CVE-2015-0287 - ASN.1 structure reuse memory corruption CVE-2015-0288 - X509_to_X509_REQ NULL pointer deref CVE-2015-0289 - PKCS7 NULL pointer dereferences Several other issues did not apply or were already fixed. Refer to https://www.openssl.org/news/secadv_20150319.txt joint work with beck, doug, guenther, jsing, miod This commit was manufactured by cvs2git to create branch 'OPENBSD_5_7'. 2015-03-08T16:48:49+00:00 cvs2svn admin@example.com 2015-03-08T16:48:49+00:00 urn:sha1:03e0d0748934886665c3031cda5fdccf45f2fb8d Reject DH keys sent by a server if they are considered too small; inspired 2015-03-08T16:48:47+00:00 miod 2015-03-08T16:48:47+00:00 urn:sha1:973703db67a8e73d70e63afa8f2cde19da09144d by a similar BoringSSL change, but raising the limit to 1024 bits. ok jsing@ markus@ guenther@ deraadt@ Do not use sha512-parisc for now, as it is subtly bugged - passes the sha 2015-03-05T20:35:28+00:00 miod 2015-03-05T20:35:28+00:00 urn:sha1:edab9f054cd9e7b7c2bb8b5683f63e8a6eaea617 regress tests but causes tls ciphersuite using sha386 to fail; found the hard way by henning@. I can't see anything wrong in the generated assembly code yet, but building a libcrypto with no assembler code but sha512_block_data_order() is enough to trigger Henning's issue, so the bug lies there. No ABI change; ok deraadt@ subtraction is not comparison. the difference of two longs is not good 2015-03-05T17:15:48+00:00 tedu 2015-03-05T17:15:48+00:00 urn:sha1:bf58bb001edc46b2379dc4ced51d2d2e084c70d8 to place in an int. from Christian Neukirchen ok deraadt Update comment to match code; Caspar Schutijser 2015-03-02T21:41:08+00:00 millert 2015-03-02T21:41:08+00:00 urn:sha1:f6e9eb23339296eec0a10399b584cbdf4948b62f Fix a minor information leak that was introduced in t1_lib.c r1.71, whereby 2015-03-02T13:43:09+00:00 jsing 2015-03-02T13:43:09+00:00 urn:sha1:45ee9e335c1b859ecec006aefb1a3c604a1c8d29 an additional 28 bytes of .rodata (or .data) is provided to the network. In most cases this is a non-issue since the memory content is already public. Issue found and reported by Felix Groebert of the Google Security Team. ok bcook@ beck@ use correct formatter (int, because of type promotion after operations) 2015-03-02T07:51:25+00:00 bcook 2015-03-02T07:51:25+00:00 urn:sha1:d8491142a00ece47c5cc94cd42e8ac2c83a9ef28 ok jsing@