November 2016 - Arch-security - lists.archlinux.org

[arch-security] [ASA-201611-9] libcurl-gnutls: multiple issues
by Levente Polyak 03 Nov '16

03 Nov '16

Arch Linux Security Advisory ASA-201611-9 ========================================= Severity: High Date : 2016-11-03 CVE-ID : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8619 CVE-2016-8621 CVE-2016-8622 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 Package : libcurl-gnutls Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package libcurl-gnutls before version 7.51.0-1 is vulnerable to multiple issues including arbitrary code execution, content spoofing, information disclosure, insufficient validation and authentication bypass. Resolution ========== Upgrade to 7.51.0-1. # pacman -Syu "libcurl-gnutls>=7.51.0-1" The problems have been fixed upstream in version 7.51.0. Workaround ========== None. Description =========== - CVE-2016-8615 (content spoofing) If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar. The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed-size buffer in a line-by- line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output. This way, a very long cookie (name + value) sent by a malicious server would be stored in the file and subsequently that cookie could be read partially and crafted correctly, it could be treated as a different cookie for another server. - CVE-2016-8616 (authentication bypass) When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password. - CVE-2016-8617 (arbitrary code execution) In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via CURLOPT_USERNAME (or curl's -u, --user option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8619 (arbitrary code execution) In curl's implementation of the Kerberos authentication mechanism, the function read_data() in security.c is used to fill the necessary krb5 structures. When reading one of the length fields from the socket, it fails to ensure that the length parameter passed to realloc() is not set to 0. This would lead to realloc() getting called with a zero size and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This flaw could be triggered by a malicious or just otherwise ill- behaving server. - CVE-2016-8621 (information disclosure) The curl_getdate converts a given date string into a numerical timestamp and it supports a range of different formats and possibilites to express a date and time. The underlying date parsing function is also used internally when parsing for example HTTP cookies (possibly received from remote servers) and it can be used when doing conditional HTTP requests. The date parser function uses the libc sscanf() function at two places, with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent being that it would parse either a string with HH:MM (two digits colon two digits) or HH:MM:SS (two digits colon two digits colon two digits). If instead the piece of time that was sent in had the final digit cut off, thus ending with a single-digit, the date parser code would advance its read pointer one byte too much and end up reading out of bounds. - CVE-2016-8622 (arbitrary code execution) The URL percent-encoding decode function in libcurl is called curl_easy_unescape. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer. This can be triggered by a user on a 64bit system if the user can send in a custom (very large) URL to a libcurl using program. - CVE-2016-8623 (arbitrary code execution) libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That function however only returns a list with references back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after- free can occur possibly leading to arbitrary code execution. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. - CVE-2016-8624 (insufficient validation) curl doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use a URL parser that follows the RFC to check for allowed domains before using curl to request them. Passing in http://example.com#@evil.com/x.txt would wrongly make curl send a request to evil.com while your browser would connect to example.com given the same URL. The problem exists for most protocol schemes. - CVE-2016-8625 (insufficient validation) When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. Impact ====== A remote attacker is able to execute arbitrary code, inject cookies for arbitrary domains and disclose sensitive information via various vectors. References ========== https://curl.haxx.se/changes.html#7_51_0 https://curl.haxx.se/docs/adv_20161102A.html https://curl.haxx.se/docs/adv_20161102B.html https://curl.haxx.se/docs/adv_20161102C.html https://curl.haxx.se/docs/adv_20161102E.html https://curl.haxx.se/docs/adv_20161102G.html https://curl.haxx.se/docs/adv_20161102H.html https://curl.haxx.se/docs/adv_20161102I.html https://curl.haxx.se/docs/adv_20161102J.html https://curl.haxx.se/docs/adv_20161102K.html https://access.redhat.com/security/cve/CVE-2016-8615 https://access.redhat.com/security/cve/CVE-2016-8616 https://access.redhat.com/security/cve/CVE-2016-8617 https://access.redhat.com/security/cve/CVE-2016-8619 https://access.redhat.com/security/cve/CVE-2016-8621 https://access.redhat.com/security/cve/CVE-2016-8622 https://access.redhat.com/security/cve/CVE-2016-8623 https://access.redhat.com/security/cve/CVE-2016-8624 https://access.redhat.com/security/cve/CVE-2016-8625

1 0

[arch-security] [ASA-201611-8] libcurl-compat: multiple issues
by Levente Polyak 03 Nov '16

03 Nov '16

Arch Linux Security Advisory ASA-201611-8 ========================================= Severity: High Date : 2016-11-03 CVE-ID : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8619 CVE-2016-8621 CVE-2016-8622 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 Package : libcurl-compat Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package libcurl-compat before version 7.51.0-1 is vulnerable to multiple issues including arbitrary code execution, content spoofing, information disclosure, insufficient validation and authentication bypass. Resolution ========== Upgrade to 7.51.0-1. # pacman -Syu "libcurl-compat>=7.51.0-1" The problems have been fixed upstream in version 7.51.0. Workaround ========== None. Description =========== - CVE-2016-8615 (content spoofing) If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar. The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed-size buffer in a line-by- line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output. This way, a very long cookie (name + value) sent by a malicious server would be stored in the file and subsequently that cookie could be read partially and crafted correctly, it could be treated as a different cookie for another server. - CVE-2016-8616 (authentication bypass) When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password. - CVE-2016-8617 (arbitrary code execution) In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via CURLOPT_USERNAME (or curl's -u, --user option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8619 (arbitrary code execution) In curl's implementation of the Kerberos authentication mechanism, the function read_data() in security.c is used to fill the necessary krb5 structures. When reading one of the length fields from the socket, it fails to ensure that the length parameter passed to realloc() is not set to 0. This would lead to realloc() getting called with a zero size and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This flaw could be triggered by a malicious or just otherwise ill- behaving server. - CVE-2016-8621 (information disclosure) The curl_getdate converts a given date string into a numerical timestamp and it supports a range of different formats and possibilites to express a date and time. The underlying date parsing function is also used internally when parsing for example HTTP cookies (possibly received from remote servers) and it can be used when doing conditional HTTP requests. The date parser function uses the libc sscanf() function at two places, with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent being that it would parse either a string with HH:MM (two digits colon two digits) or HH:MM:SS (two digits colon two digits colon two digits). If instead the piece of time that was sent in had the final digit cut off, thus ending with a single-digit, the date parser code would advance its read pointer one byte too much and end up reading out of bounds. - CVE-2016-8622 (arbitrary code execution) The URL percent-encoding decode function in libcurl is called curl_easy_unescape. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer. This can be triggered by a user on a 64bit system if the user can send in a custom (very large) URL to a libcurl using program. - CVE-2016-8623 (arbitrary code execution) libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That function however only returns a list with references back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after- free can occur possibly leading to arbitrary code execution. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. - CVE-2016-8624 (insufficient validation) curl doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use a URL parser that follows the RFC to check for allowed domains before using curl to request them. Passing in http://example.com#@evil.com/x.txt would wrongly make curl send a request to evil.com while your browser would connect to example.com given the same URL. The problem exists for most protocol schemes. - CVE-2016-8625 (insufficient validation) When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. Impact ====== A remote attacker is able to execute arbitrary code, inject cookies for arbitrary domains and disclose sensitive information via various vectors. References ========== https://curl.haxx.se/changes.html#7_51_0 https://curl.haxx.se/docs/adv_20161102A.html https://curl.haxx.se/docs/adv_20161102B.html https://curl.haxx.se/docs/adv_20161102C.html https://curl.haxx.se/docs/adv_20161102E.html https://curl.haxx.se/docs/adv_20161102G.html https://curl.haxx.se/docs/adv_20161102H.html https://curl.haxx.se/docs/adv_20161102I.html https://curl.haxx.se/docs/adv_20161102J.html https://curl.haxx.se/docs/adv_20161102K.html https://access.redhat.com/security/cve/CVE-2016-8615 https://access.redhat.com/security/cve/CVE-2016-8616 https://access.redhat.com/security/cve/CVE-2016-8617 https://access.redhat.com/security/cve/CVE-2016-8619 https://access.redhat.com/security/cve/CVE-2016-8621 https://access.redhat.com/security/cve/CVE-2016-8622 https://access.redhat.com/security/cve/CVE-2016-8623 https://access.redhat.com/security/cve/CVE-2016-8624 https://access.redhat.com/security/cve/CVE-2016-8625

1 0

[arch-security] [ASA-201611-7] curl: multiple issues
by Levente Polyak 03 Nov '16

03 Nov '16

Arch Linux Security Advisory ASA-201611-7 ========================================= Severity: High Date : 2016-11-03 CVE-ID : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8619 CVE-2016-8620 CVE-2016-8621 CVE-2016-8622 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 Package : curl Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package curl before version 7.51.0-1 is vulnerable to multiple issues including arbitrary code execution, content spoofing, information disclosure, insufficient validation and authentication bypass. Resolution ========== Upgrade to 7.51.0-1. # pacman -Syu "curl>=7.51.0-1" The problems have been fixed upstream in version 7.51.0. Workaround ========== None. Description =========== - CVE-2016-8615 (content spoofing) If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar. The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed-size buffer in a line-by- line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output. This way, a very long cookie (name + value) sent by a malicious server would be stored in the file and subsequently that cookie could be read partially and crafted correctly, it could be treated as a different cookie for another server. - CVE-2016-8616 (authentication bypass) When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password. - CVE-2016-8617 (arbitrary code execution) In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via CURLOPT_USERNAME (or curl's -u, --user option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8619 (arbitrary code execution) In curl's implementation of the Kerberos authentication mechanism, the function read_data() in security.c is used to fill the necessary krb5 structures. When reading one of the length fields from the socket, it fails to ensure that the length parameter passed to realloc() is not set to 0. This would lead to realloc() getting called with a zero size and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This flaw could be triggered by a malicious or just otherwise ill- behaving server. - CVE-2016-8620 (arbitrary code execution) The curl tool's "globbing" feature allows a user to specify a numerical range through which curl will iterate. It is typically specified as [1-5], specifying the first and the last numbers in the range. Or with [a-z], using letters. The curl code for parsing the second unsigned number did not check for a leading minus character, which allowed a user to specify [1--1] with no complaints and have the latter -1 number get turned into the largest unsigned long value the system can handle. This would ultimately cause curl to write outside the dedicated malloced buffer after no less than 100,000 iterations, since it would have room for 5 digits but not 6. When the range is specified with letters, and the ending letter is left out [L-], the code would still advance its read pointer 5 bytes even if the string was just 4 bytes and end up reading outside the given buffer. This flaw exists only in the curl tool, not in the libcurl library. - CVE-2016-8621 (information disclosure) The curl_getdate converts a given date string into a numerical timestamp and it supports a range of different formats and possibilites to express a date and time. The underlying date parsing function is also used internally when parsing for example HTTP cookies (possibly received from remote servers) and it can be used when doing conditional HTTP requests. The date parser function uses the libc sscanf() function at two places, with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent being that it would parse either a string with HH:MM (two digits colon two digits) or HH:MM:SS (two digits colon two digits colon two digits). If instead the piece of time that was sent in had the final digit cut off, thus ending with a single-digit, the date parser code would advance its read pointer one byte too much and end up reading out of bounds. - CVE-2016-8622 (arbitrary code execution) The URL percent-encoding decode function in libcurl is called curl_easy_unescape. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer. This can be triggered by a user on a 64bit system if the user can send in a custom (very large) URL to a libcurl using program. - CVE-2016-8623 (arbitrary code execution) libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That function however only returns a list with references back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after- free can occur possibly leading to arbitrary code execution. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. - CVE-2016-8624 (insufficient validation) curl doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use a URL parser that follows the RFC to check for allowed domains before using curl to request them. Passing in http://example.com#@evil.com/x.txt would wrongly make curl send a request to evil.com while your browser would connect to example.com given the same URL. The problem exists for most protocol schemes. - CVE-2016-8625 (insufficient validation) When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. Impact ====== A remote attacker is able to execute arbitrary code, inject cookies for arbitrary domains and disclose sensitive information via various vectors. References ========== https://curl.haxx.se/changes.html#7_51_0 https://curl.haxx.se/docs/adv_20161102A.html https://curl.haxx.se/docs/adv_20161102B.html https://curl.haxx.se/docs/adv_20161102C.html https://curl.haxx.se/docs/adv_20161102E.html https://curl.haxx.se/docs/adv_20161102F.html https://curl.haxx.se/docs/adv_20161102G.html https://curl.haxx.se/docs/adv_20161102H.html https://curl.haxx.se/docs/adv_20161102I.html https://curl.haxx.se/docs/adv_20161102J.html https://curl.haxx.se/docs/adv_20161102K.html https://access.redhat.com/security/cve/CVE-2016-8615 https://access.redhat.com/security/cve/CVE-2016-8616 https://access.redhat.com/security/cve/CVE-2016-8617 https://access.redhat.com/security/cve/CVE-2016-8619 https://access.redhat.com/security/cve/CVE-2016-8620 https://access.redhat.com/security/cve/CVE-2016-8621 https://access.redhat.com/security/cve/CVE-2016-8622 https://access.redhat.com/security/cve/CVE-2016-8623 https://access.redhat.com/security/cve/CVE-2016-8624 https://access.redhat.com/security/cve/CVE-2016-8625

1 0

[arch-security] [ASA-201611-6] tomcat6: proxy injection
by Levente Polyak 02 Nov '16

02 Nov '16

Arch Linux Security Advisory ASA-201611-6 ========================================= Severity: Medium Date : 2016-11-02 CVE-ID : CVE-2016-5388 Package : tomcat6 Type : proxy injection Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package tomcat6 before version 6.0.47-1 is vulnerable to proxy injection. Resolution ========== Upgrade to 6.0.47-1. # pacman -Syu "tomcat6>=6.0.47-1" The problem has been fixed upstream in version 6.0.47. Workaround ========== None. Description =========== It was discovered that tomcat used the value of the Proxy header from HTTP requests to initialize the HTTP_PROXY environment variable for CGI scripts, which in turn was incorrectly used by certain HTTP client implementations to configure the proxy for outgoing HTTP requests. A remote attacker could possibly use this flaw to redirect HTTP requests performed by a CGI script to an attacker-controlled proxy via a malicious HTTP request. Impact ====== A remote attacker is able to use this flaw to redirect HTTP requests performed by a CGI script to an attacker-controlled proxy via a malicious HTTP request. References ========== https://www.apache.org/security/asf-httpoxy-response.txt https://access.redhat.com/security/cve/CVE-2016-5388

1 0

[arch-security] [ASA-201611-5] lib32-libcurl-compat: multiple issues
by Levente Polyak 02 Nov '16

02 Nov '16

Arch Linux Security Advisory ASA-201611-5 ========================================= Severity: High Date : 2016-11-02 CVE-ID : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8618 CVE-2016-8619 CVE-2016-8621 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 Package : lib32-libcurl-compat Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package lib32-libcurl-compat before version 7.51.0-1 is vulnerable to multiple issues including arbitrary code execution, content spoofing, information disclosure, insufficient validation and authentication bypass. Resolution ========== Upgrade to 7.51.0-1. # pacman -Syu "lib32-libcurl-compat>=7.51.0-1" The problems have been fixed upstream in version 7.51.0. Workaround ========== None. Description =========== - CVE-2016-8615 (content spoofing) If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar. The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed-size buffer in a line-by- line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output. This way, a very long cookie (name + value) sent by a malicious server would be stored in the file and subsequently that cookie could be read partially and crafted correctly, it could be treated as a different cookie for another server. - CVE-2016-8616 (authentication bypass) When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password. - CVE-2016-8617 (arbitrary code execution) In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via CURLOPT_USERNAME (or curl's -u, --user option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8618 (arbitrary code execution) The libcurl API function called curl_maprintf() can be tricked into doing a double-free due to an unsafe size_t multiplication, on systems using 32 bit size_t variables. The function is also used internally in numerous situations. The function doubles an allocated memory area with realloc() and allows the size to wrap and become zero and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This behavior is triggerable using the publicly exposed function. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8619 (arbitrary code execution) In curl's implementation of the Kerberos authentication mechanism, the function read_data() in security.c is used to fill the necessary krb5 structures. When reading one of the length fields from the socket, it fails to ensure that the length parameter passed to realloc() is not set to 0. This would lead to realloc() getting called with a zero size and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This flaw could be triggered by a malicious or just otherwise ill- behaving server. - CVE-2016-8621 (information disclosure) The curl_getdate converts a given date string into a numerical timestamp and it supports a range of different formats and possibilites to express a date and time. The underlying date parsing function is also used internally when parsing for example HTTP cookies (possibly received from remote servers) and it can be used when doing conditional HTTP requests. The date parser function uses the libc sscanf() function at two places, with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent being that it would parse either a string with HH:MM (two digits colon two digits) or HH:MM:SS (two digits colon two digits colon two digits). If instead the piece of time that was sent in had the final digit cut off, thus ending with a single-digit, the date parser code would advance its read pointer one byte too much and end up reading out of bounds. - CVE-2016-8623 (arbitrary code execution) libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That function however only returns a list with references back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after- free can occur possibly leading to arbitrary code execution. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. - CVE-2016-8624 (insufficient validation) curl doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use a URL parser that follows the RFC to check for allowed domains before using curl to request them. Passing in http://example.com#@evil.com/x.txt would wrongly make curl send a request to evil.com while your browser would connect to example.com given the same URL. The problem exists for most protocol schemes. - CVE-2016-8625 (insufficient validation) When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. Impact ====== A remote attacker is able to execute arbitrary code, inject cookies for arbitrary domains and disclose sensitive information via various vectors. References ========== https://curl.haxx.se/changes.html#7_51_0 https://curl.haxx.se/docs/adv_20161102A.html https://curl.haxx.se/docs/adv_20161102B.html https://curl.haxx.se/docs/adv_20161102C.html https://curl.haxx.se/docs/adv_20161102D.html https://curl.haxx.se/docs/adv_20161102E.html https://curl.haxx.se/docs/adv_20161102G.html https://curl.haxx.se/docs/adv_20161102I.html https://curl.haxx.se/docs/adv_20161102J.html https://curl.haxx.se/docs/adv_20161102K.html https://access.redhat.com/security/cve/CVE-2016-8615 https://access.redhat.com/security/cve/CVE-2016-8616 https://access.redhat.com/security/cve/CVE-2016-8617 https://access.redhat.com/security/cve/CVE-2016-8618 https://access.redhat.com/security/cve/CVE-2016-8619 https://access.redhat.com/security/cve/CVE-2016-8621 https://access.redhat.com/security/cve/CVE-2016-8623 https://access.redhat.com/security/cve/CVE-2016-8624 https://access.redhat.com/security/cve/CVE-2016-8625

1 0

[arch-security] [ASA-201611-4] lib32-curl: multiple issues
by Levente Polyak 02 Nov '16

02 Nov '16

Arch Linux Security Advisory ASA-201611-4 ========================================= Severity: High Date : 2016-11-02 CVE-ID : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8618 CVE-2016-8619 CVE-2016-8621 CVE-2016-8623 CVE-2016-8624 CVE-2016-8625 Package : lib32-curl Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package lib32-curl before version 7.51.0-1 is vulnerable to multiple issues including arbitrary code execution, content spoofing, information disclosure, insufficient validation and authentication bypass. Resolution ========== Upgrade to 7.51.0-1. # pacman -Syu "lib32-curl>=7.51.0-1" The problems have been fixed upstream in version 7.51.0. Workaround ========== None. Description =========== - CVE-2016-8615 (content spoofing) If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar. The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed-size buffer in a line-by- line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output. This way, a very long cookie (name + value) sent by a malicious server would be stored in the file and subsequently that cookie could be read partially and crafted correctly, it could be treated as a different cookie for another server. - CVE-2016-8616 (authentication bypass) When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password. - CVE-2016-8617 (arbitrary code execution) In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via CURLOPT_USERNAME (or curl's -u, --user option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8618 (arbitrary code execution) The libcurl API function called curl_maprintf() can be tricked into doing a double-free due to an unsafe size_t multiplication, on systems using 32 bit size_t variables. The function is also used internally in numerous situations. The function doubles an allocated memory area with realloc() and allows the size to wrap and become zero and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This behavior is triggerable using the publicly exposed function. Systems with 64 bit versions of the size_t type are not affected by this issue. - CVE-2016-8619 (arbitrary code execution) In curl's implementation of the Kerberos authentication mechanism, the function read_data() in security.c is used to fill the necessary krb5 structures. When reading one of the length fields from the socket, it fails to ensure that the length parameter passed to realloc() is not set to 0. This would lead to realloc() getting called with a zero size and when doing so realloc() returns NULL and frees the memory - in contrary to normal realloc() fails where it only returns NULL - causing libcurl to free the memory again in the error path. This flaw could be triggered by a malicious or just otherwise ill- behaving server. - CVE-2016-8621 (information disclosure) The curl_getdate converts a given date string into a numerical timestamp and it supports a range of different formats and possibilites to express a date and time. The underlying date parsing function is also used internally when parsing for example HTTP cookies (possibly received from remote servers) and it can be used when doing conditional HTTP requests. The date parser function uses the libc sscanf() function at two places, with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent being that it would parse either a string with HH:MM (two digits colon two digits) or HH:MM:SS (two digits colon two digits colon two digits). If instead the piece of time that was sent in had the final digit cut off, thus ending with a single-digit, the date parser code would advance its read pointer one byte too much and end up reading out of bounds. - CVE-2016-8623 (arbitrary code execution) libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That function however only returns a list with references back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after- free can occur possibly leading to arbitrary code execution. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. - CVE-2016-8624 (insufficient validation) curl doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use a URL parser that follows the RFC to check for allowed domains before using curl to request them. Passing in http://example.com#@evil.com/x.txt would wrongly make curl send a request to evil.com while your browser would connect to example.com given the same URL. The problem exists for most protocol schemes. - CVE-2016-8625 (insufficient validation) When curl is built with libidn to handle International Domain Names (IDNA), it translates them to puny code for DNS resolving using the IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA standard. This misalignment causes problems with for example domains using the German ß character (known as the Unicode Character 'LATIN SMALL LETTER SHARP S') which is used at times in the .de TLD and is translated differently in the two IDNA standards, leading to users potentially and unknowingly issuing network transfer requests to the wrong host. For example, straße.de is translated into strasse.de using IDNA 2003 but is translated into xn--strae-oqa.de using IDNA 2008. Needless to say, those host names could very well resolve to different addresses and be two completely independent servers. IDNA 2008 is mandatory for .de domains. This name problem exists for DNS-using protocols in curl, but only when built to use libidn. Impact ====== A remote attacker is able to execute arbitrary code, inject cookies for arbitrary domains and disclose sensitive information via various vectors. References ========== https://curl.haxx.se/changes.html#7_51_0 https://curl.haxx.se/docs/adv_20161102A.html https://curl.haxx.se/docs/adv_20161102B.html https://curl.haxx.se/docs/adv_20161102C.html https://curl.haxx.se/docs/adv_20161102D.html https://curl.haxx.se/docs/adv_20161102E.html https://curl.haxx.se/docs/adv_20161102G.html https://curl.haxx.se/docs/adv_20161102I.html https://curl.haxx.se/docs/adv_20161102J.html https://curl.haxx.se/docs/adv_20161102K.html https://access.redhat.com/security/cve/CVE-2016-8615 https://access.redhat.com/security/cve/CVE-2016-8616 https://access.redhat.com/security/cve/CVE-2016-8617 https://access.redhat.com/security/cve/CVE-2016-8618 https://access.redhat.com/security/cve/CVE-2016-8619 https://access.redhat.com/security/cve/CVE-2016-8621 https://access.redhat.com/security/cve/CVE-2016-8623 https://access.redhat.com/security/cve/CVE-2016-8624 https://access.redhat.com/security/cve/CVE-2016-8625

1 0

[arch-security] [ASA-201611-3] bind: denial of service
by Santiago Torres-Arias 01 Nov '16

01 Nov '16

Arch Linux Security Advisory ASA-201611-3 ========================================= Severity: High Date : 2016-11-01 CVE-ID : CVE-2016-8864 Package : bind Type : denial of service Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package bind before version 9.11.0.P1-1 is vulnerable to denial of service. Resolution ========== Upgrade to 9.11.0.P1-1. # pacman -Syu "bind>=9.11.0.P1-1" The problem has been fixed upstream in version 9.11.0.P1. Workaround ========== None. Description =========== A defect in BIND's handling of responses containing a DNAME answer can cause a resolver to exit after encountering an assertion failure in db.c or resolver.c During processing of a recursive response that contains a DNAME record in the answer section, BIND can stop execution after encountering an assertion error in resolver.c (error message: "INSIST((valoptions & 0x0002U) != 0) failed") or db.c (error message: "REQUIRE(targetp != ((void *)0) && *targetp == ((void *)0)) failed"). A server encountering either of these error conditions will stop, resulting in denial of service to clients. The risk to authoritative servers is minimal; recursive servers are chiefly at risk. Impact ====== An attacker can send a crafted DNAME answer to crash the application. References ========== https://kb.isc.org/article/AA-01434/0 https://ftp.isc.org/isc/bind9/9.11.0-P1/RELEASE-NOTES-bind-9.11.0-P1.html https://access.redhat.com/security/cve/CVE-2016-8864

1 0

[arch-security] [ASA-201611-2] libxml2: arbitrary code execution
by Levente Polyak 01 Nov '16

01 Nov '16

Arch Linux Security Advisory ASA-201611-2 ========================================= Severity: Critical Date : 2016-11-01 CVE-ID : CVE-2016-4658 CVE-2016-5131 Package : libxml2 Type : arbitrary code execution Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package libxml2 before version 2.9.4+12+ge905f08-1 is vulnerable to arbitrary code execution. Resolution ========== Upgrade to 2.9.4+12+ge905f08-1. # pacman -Syu "libxml2>=2.9.4+12+ge905f08-1" The problems have been fixed upstream but no release is available yet. Workaround ========== None. Description =========== - CVE-2016-4658 (arbitrary code execution) A use-after-free vulnerability via namespace nodes in XPointer ranges was found in libxml2. - CVE-2016-5131 (arbitrary code execution) Bugs in xmlXPathEvalExpr and xmlXPtrRangeToFunction can lead to a use- after-free and allow control of the instruction pointer. Impact ====== A remote attacker is able to use a specially crafted XPath payload to execute arbitrary code. References ========== https://bugzilla.redhat.com/show_bug.cgi?id=1384424 https://git.gnome.org/browse/libxml2/commit/?id=c1d1f7121194036608bf555f08d… https://git.gnome.org/browse/libxml2/commit/?id=9ab01a277d71f54d3143c2cf333… https://bugs.chromium.org/p/chromium/issues/detail?id=623378 https://access.redhat.com/security/cve/CVE-2016-4658 https://access.redhat.com/security/cve/CVE-2016-5131

1 0

[arch-security] [ASA-201611-1] memcached: arbitrary code execution
by Remi Gacogne 01 Nov '16

01 Nov '16

Arch Linux Security Advisory ASA-201611-1 ========================================= Severity: Critical Date : 2016-11-01 CVE-ID : CVE-2016-8704 CVE-2016-8705 CVE-2016-8706 Package : memcached Type : arbitrary code execution Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package memcached before version 1.4.32-1 is vulnerable to arbitrary code execution. Resolution ========== Upgrade to 1.4.32-1. # pacman -Syu "memcached>=1.4.32-1" The problems have been fixed upstream in version 1.4.32. Workaround ========== If you do not use the binary protocol at all, a workaround is to start memcached with "-B ascii" to disable it. Description =========== - CVE-2016-8704 (arbitrary code execution) An integer overflow in the process_bin_append_prepend function which is responsible for processing multiple commands of Memcached binary protocol can be abused to cause heap overflow and lead to remote code execution. - CVE-2016-8705 (arbitrary code execution) Multiple integer overflows in process_bin_update function which is responsible for processing multiple commands of Memcached binary protocol can be abused to cause heap overflow and lead to remote code execution. - CVE-2016-8706 (arbitrary code execution) An integer overflow in process_bin_sasl_auth function which is responsible for authentication commands of Memcached binary protocol can be abused to cause heap overflow and lead to remote code execution. Impact ====== A remote unauthenticated attacker can execute arbitrary code on the affected host. References ========== http://www.talosintelligence.com/reports/TALOS-2016-0219/ http://www.talosintelligence.com/reports/TALOS-2016-0220/ http://www.talosintelligence.com/reports/TALOS-2016-0221/ http://blog.talosintel.com/2016/10/memcached-vulnerabilities.html https://github.com/memcached/memcached/wiki/ReleaseNotes1433 https://access.redhat.com/security/cve/CVE-2016-8704 https://access.redhat.com/security/cve/CVE-2016-8705 https://access.redhat.com/security/cve/CVE-2016-8706

1 0