{"push_id":1010933960,"size":4,"distinct_size":4,"ref":"refs/heads/freifunk-berlin/for-kathleen-0.2_unstable","head":"eb430189ceaf38b2f018a1a575f52392559fa328","before":"37fc25a63766a235497ad09380a9e90c3da36f4f","commits":[{"sha":"90d95cabebf389be89152e46f0d69cfeace5b614","author":{"email":"118ed6118e893d16e8c6e0776e0ebc290952c897@3c298f89-4303-0410-b956-a3cf2f4a3e73","name":"nbd"},"message":"openssl: update to 1.0.2f (fixes CVE-2016-0701, CVE-2015-3197)\n\nSigned-off-by: Felix Fietkau <nbd@openwrt.org>\n\nBackport of r48531\n\ngit-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48532 3c298f89-4303-0410-b956-a3cf2f4a3e73","distinct":true,"url":"https://api.github.com/repos/SvenRoederer/openwrt-openwrt/commits/90d95cabebf389be89152e46f0d69cfeace5b614"},{"sha":"84bd677c027495bd42e9f0bd6f5f19c1a7d9afd8","author":{"email":"be6487f9df4dce44a640672d6c07330104d43593@3c298f89-4303-0410-b956-a3cf2f4a3e73","name":"blogic"},"message":"OpenSSL: Added source/old to PKG_SOURCE_URL\n\nOpenSSL moves old versions of the library from\nhttp://www.openssl.org/source/ to\nhttp://www.openssl.org/source/old/$version/ breaking the old links.\nThat behavior breaks the OpenWRT-build every time OpenSSL releases\na new version.\n\nThis patch adds http://www.openssl.org/source/old/$version/ to the\nPKG_SOURCE_URL of OpenSSL to avoid breaking the build whenever\nOpenSSL releases a new version.\n\nSigned-off-by: Kevin Kirsch <ranlvor@starletp9.de>\nReviewed-by: Alexander Dahl <post@lespocky.de>\n\nBackport of r47860\n\ngit-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48845 3c298f89-4303-0410-b956-a3cf2f4a3e73","distinct":true,"url":"https://api.github.com/repos/SvenRoederer/openwrt-openwrt/commits/84bd677c027495bd42e9f0bd6f5f19c1a7d9afd8"},{"sha":"07a01298429f5ed0b7f9eba334b1d6f5dc96a958","author":{"email":"a9275913d515487ffaed469337a530ed202da558@3c298f89-4303-0410-b956-a3cf2f4a3e73","name":"jow"},"message":"CC: openssl: update to 1.0.2g (8 CVEs)\n\nCVE-2016-0704\n\ns2_srvr.c overwrite the wrong bytes in the master-key when applying\nBleichenbacher protection for export cipher suites. This provides a\nBleichenbacher oracle, and could potentially allow more efficient variants of\nthe DROWN attack.\n\nCVE-2016-0703\n\ns2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers.\nIf clear-key bytes are present for these ciphers, they *displace* encrypted-key\nbytes. This leads to an efficient divide-and-conquer key recovery attack: if\nan eavesdropper has intercepted an SSLv2 handshake, they can use the server as\nan oracle to determine the SSLv2 master-key, using only 16 connections to the\nserver and negligible computation. More importantly, this leads to a more\nefficient version of DROWN that is effective against non-export ciphersuites,\nand requires no significant computation.\n\nCVE-2016-0702\n\nA side-channel attack was found which makes use of cache-bank conflicts on\nthe Intel Sandy-Bridge microarchitecture which could lead to the recovery of\nRSA keys. The ability to exploit this issue is limited as it relies on an\nattacker who has control of code in a thread running on the same hyper-\nthreaded core as the victim thread which is performing decryptions.\n\nCVE-2016-0799\n\nThe internal |fmtstr| function used in processing a \"%s\" format string in\nthe BIO_*printf functions could overflow while calculating the length of a\nstring and cause an OOB read when printing very long strings. Additionally\nthe internal |doapr_outch| function can attempt to write to an OOB memory\nlocation (at an offset from the NULL pointer) in the event of a memory\nallocation failure. In 1.0.2 and below this could be caused where the size\nof a buffer to be allocated is greater than INT_MAX. E.g. this could be in\nprocessing a very long \"%s\" format string. Memory leaks can also occur.\nThe first issue may mask the second issue dependent on compiler behaviour.\nThese problems could enable attacks where large amounts of untrusted data is\npassed to the BIO_*printf functions. If applications use these functions in\nthis way then they could be vulnerable. OpenSSL itself uses these functions\nwhen printing out human-readable dumps of ASN.1 data. Therefore applications\nthat print this data could be vulnerable if the data is from untrusted sources.\nOpenSSL command line applications could also be vulnerable where they print out\nASN.1 data, or if untrusted data is passed as command line arguments. Libssl is\nnot considered directly vulnerable. Additionally certificates etc received via\nremote connections via libssl are also unlikely to be able to trigger these\nissues because of message size limits enforced within libssl.\n\nCVE-2016-0797\n\nIn the BN_hex2bn function the number of hex digits is calculated using an int\nvalue |i|. Later |bn_expand| is called with a value of |i * 4|. For large\nvalues of |i| this can result in |bn_expand| not allocating any memory because\n|i * 4| is negative. This can leave the internal BIGNUM data field as NULL\nleading to a subsequent NULL ptr deref. For very large values of |i|, the\ncalculation |i * 4| could be a positive value smaller than |i|. In this case\nmemory is allocated to the internal BIGNUM data field, but it is insufficiently\nsized leading to heap corruption. A similar issue exists in BN_dec2bn. This\ncould have security consequences if BN_hex2bn/BN_dec2bn is ever called by user\napplications with very large untrusted hex/dec data. This is anticipated to be\na rare occurrence. All OpenSSL internal usage of these functions use data that\nis not expected to be untrusted, e.g. config file data or application command\nline arguments. If user developed applications generate config file data based\non untrusted data then it is possible that this could also lead to security\nconsequences. This is also anticipated to be rare.\n\nCVE-2016-0798\n\nThe SRP user database lookup method SRP_VBASE_get_by_user had confusing memory\nmanagement semantics; the returned pointer was sometimes newly allocated, and\nsometimes owned by the callee. The calling code has no way of distinguishing\nthese two cases. Specifically, SRP servers that configure a secret seed to hide\nvalid login information are vulnerable to a memory leak: an attacker connecting\nwith an invalid username can cause a memory leak of around 300 bytes per\nconnection. Servers that do not configure SRP, or configure SRP but do not\nconfigure a seed are not vulnerable. In Apache, the seed directive is known as\nSSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in\nSRP_VBASE_get_by_user is now disabled even if the user has configured a seed.\nApplications are advised to migrate to SRP_VBASE_get1_by_user. However, note\nthat OpenSSL makes no strong guarantees about the indistinguishability of valid\nand invalid logins. In particular, computations are currently not carried out\nin constant time.\n\nCVE-2016-0705\n\nA double free bug was discovered when OpenSSL parses malformed DSA private keys\nand could lead to a DoS attack or memory corruption for applications that\nreceive DSA private keys from untrusted sources. This scenario is considered\nrare.\n\nCVE-2016-0800\n\nA cross-protocol attack was discovered that could lead to decryption of TLS\nsessions by using a server supporting SSLv2 and EXPORT cipher suites as a\nBleichenbacher RSA padding oracle. Note that traffic between clients and non-\nvulnerable servers can be decrypted provided another server supporting SSLv2\nand EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP)\nshares the RSA keys of the non-vulnerable server. This vulnerability is known\nas DROWN (CVE-2016-0800). Recovering one session key requires the attacker to\nperform approximately 2^50 computation, as well as thousands of connections to\nthe affected server. A more efficient variant of the DROWN attack exists\nagainst unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m,\n1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below). Users can\navoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers,\nif they've not done so already. Disabling all SSLv2 ciphers is also sufficient,\nprovided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f)\nhave been deployed. Servers that have not disabled the SSLv2 protocol, and are\nnot patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2\nciphers are nominally disabled, because malicious clients can force the use of\nSSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the following\nmitigation against DROWN: SSLv2 is now by default disabled at build-time.\nBuilds that are not configured with \"enable-ssl2\" will not support SSLv2.\nEven if \"enable-ssl2\" is used, users who want to negotiate SSLv2 via the\nversion-flexible SSLv23_method() will need to explicitly call either of:\nSSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl,\nSSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the\napplication explicitly uses the version-specific SSLv2_method() or its client\nor server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery\nhave been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2\n56-bit DES are no longer available. In addition, weak ciphers in SSLv3 and up\nare now disabled in default builds of OpenSSL. Builds that are not configured\nwith \"enable-weak-ssl-ciphers\" will not provide any \"EXPORT\" or \"LOW\" strength\nciphers.\n\nSigned-off-by: Jo-Philipp Wich <jow@openwrt.org>\n\nBackport of r48868.\n\ngit-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@48869 3c298f89-4303-0410-b956-a3cf2f4a3e73","distinct":true,"url":"https://api.github.com/repos/SvenRoederer/openwrt-openwrt/commits/07a01298429f5ed0b7f9eba334b1d6f5dc96a958"},{"sha":"eb430189ceaf38b2f018a1a575f52392559fa328","author":{"email":"f304a8489b18cb178859c91cbdfec17ca74fbd64@geroedel.de","name":"Sven Roederer"},"message":"Merge branch 'wip-cc/security-fixes' into freifunk-berlin/for-kathleen-0.2_unstable\n\n- OpenSSL","distinct":true,"url":"https://api.github.com/repos/SvenRoederer/openwrt-openwrt/commits/eb430189ceaf38b2f018a1a575f52392559fa328"}]}