January 2015 - Arch-security - lists.archlinux.org

[arch-security] [ASA-201501-5] cpio: heap buffer overflow
by Levente Polyak 14 Jan '15

14 Jan '15

Arch Linux Security Advisory ASA-201501-5 ========================================= Severity: Medium Date : 2015-01-14 CVE-ID : CVE-2014-9112 Package : cpio Type : heap buffer overflow Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package cpio before version 2.11-5 is vulnerable to a heap buffer overflow. Resolution ========== Upgrade to 2.11-5. # pacman -Syu "cpio>=2.11-5" The problem has been fixed upstream but no release is available yet. Workaround ========== None. Description =========== A heap-based buffer overflow flaw was reported in cpio's list_file() function. Attempting to extract a malicious cpio archive could cause cpio to crash or, potentially, execute arbitrary code. As noted in the original report, this issue could be trigger via other utilities, such as when running "less". Impact ====== An attacker is able to craft a malicious cpio archive which could cause cpio to crash or, potentially, execute arbitrary code. This issue could also be trigger via other utilities, such as when running "less". References ========== http://seclists.org/oss-sec/2014/q4/818 https://savannah.gnu.org/bugs/?43709 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9112

1 0

[arch-security] [ASA-201501-4] libevent: heap overflow
by Remi Gacogne 13 Jan '15

13 Jan '15

Arch Linux Security Advisory ASA-201501-4 ========================================= Severity: Medium Date : 2015-01-13 CVE-ID : CVE-2014-6272 Package : libevent Type : heap overflow Remote : No Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package libevent before version 2.0.22-1 is vulnerable to a potential heap overflow. Resolution ========== Upgrade to 2.0.22-1. # pacman -Syu "libevent>=2.0.22-1" The problem has been fixed upstream in version 2.0.22. Workaround ========== The potential heap overflow can be prevented by not using evbuffer_add(), evbuffer_prepend(), evbuffer_expand(), exbuffer_reserve_space(), or evbuffer_read() in a way leading to the use of a buffer chunk larger than a single size_t. Description =========== A defect in the libevent evbuffer API could possibly leave some programs that use the evbuffer API open to potential heap overflows. A program using the evbuffer_add(), evbuffer_prepend(), evbuffer_expand(), exbuffer_reserve_space(), or evbuffer_read() functions may be vulnerable if an attacker is able to coax the linked program into trying to make a buffer larger than that which would fit into a single size_t. Impact ====== An attacker may be able to execute arbitrary code in a program using a vulnerable version of libevent. Upstream has attempted to identify any programs using libevent in a vulnerable way and has not as of yet found any that do but, as a precaution, recommends upgrading. References ========== http://archives.seul.org/libevent/users/Jan-2015/msg00010.html https://bugs.archlinux.org/task/43366 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6272

1 0

[arch-security] [ASA-201501-3] unzip: arbitrary code execution
by Levente Polyak 10 Jan '15

10 Jan '15

Arch Linux Security Advisory ASA-201501-3 ========================================= Severity: High Date : 2015-01-10 CVE-ID : CVE-2014-8139 CVE-2014-8140 CVE-2014-8141 Package : unzip Type : arbitrary code execution Remote : No Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package unzip before version 6.0-9 is vulnerable to arbitrary code execution and denial of service through multiple heap buffer overflows. Resolution ========== Upgrade to 6.0-9. # pacman -Syu "unzip>=6.0-9" The problems have not been fixed upstream but patches were added. Workaround ========== None. Description =========== - CVE-2014-8139 (heap buffer overflow) A heap-based buffer overflow exists in the CRC32 verification that allows attackers to potentially execute arbitrary code or cause a denial of service (memory corruption). - CVE-2014-8140 (out-of-bounds read/write) Out-of-bounds access (both read and write) issues exist in test_compr_eb() that can result in application crash or arbitrary code execution. - CVE-2014-8141 (out-of-bounds read) Two out-of-bounds read issues exist in getZip64Data() that allows attackers to cause a denial of service. Impact ====== An attacker is able to execute arbitrary code or cause a denial of service through a specially crafted zip file passed to the command unzip -t. References ========== https://www.ocert.org/advisories/ocert-2014-011.html https://access.redhat.com/security/cve/CVE-2014-8139 https://access.redhat.com/security/cve/CVE-2014-8140 https://access.redhat.com/security/cve/CVE-2014-8141 https://bugs.archlinux.org/task/43300 https://bugs.archlinux.org/task/43391

1 0

[arch-security] [ASA-201501-2] openssl: multiple issues
by Levente Polyak 09 Jan '15

09 Jan '15

Arch Linux Security Advisory ASA-201501-2 ========================================= Severity: High Date : 2015-01-09 CVE-ID : CVE-2014-3571 CVE-2015-0206 CVE-2014-3569 CVE-2014-3572 CVE-2015-0204 CVE-2015-0205 CVE-2014-8275 CVE-2014-3570 Package : openssl Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package openssl before version 1.0.1.k-1 is vulnerable to multiple issues, including but not limited to denial of service, cipher downgrade, certificate verification bypass and certificate fingerprint modification. Resolution ========== Upgrade to 1.0.1.k-1. # pacman -Syu "openssl>=1.0.1.k-1" The problems have been fixed upstream in version 1.0.1.k. Workaround ========== None. Description =========== - CVE-2014-3571 (denial of service) A remote attacker is able to cause a denial of service (NULL pointer dereference and application crash) via a crafted DTLS message that is processed with a different read operation for the handshake header than for the handshake body, related to the dtls1_get_record function in d1_pkt.c and the ssl3_read_n function in s3_pkt.c. - CVE-2015-0206 (denial of service) A memory leak can occur in the dtls1_buffer_record function under certain conditions. In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a denial of service attack through memory exhaustion. - CVE-2014-3569 (denial of service) The ssl23_get_client_hello function in s23_srvr.c does not properly handle attempts to use unsupported protocols, which allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via an unexpected handshake, as demonstrated by an SSLv3 handshake to a no-ssl3 application with certain error handling. - CVE-2014-3572 (cipher downgrade) An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite using an ECDSA certificate if the server key exchange message is omitted. This effectively removes forward secrecy from the ciphersuite. - CVE-2015-0204 (cipher downgrade) The ssl3_get_key_exchange function in s3_clnt.c allows remote SSL servers to conduct RSA-to-EXPORT_RSA downgrade attacks and facilitate brute-force decryption by offering a weak ephemeral RSA key in a noncompliant role. - CVE-2015-0205 (certificate verification bypass) An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys. - CVE-2014-8275 (certificate fingerprint modification) OpenSSL accepts several non-DER-variations of certificate signature algorithm and signature encodings. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions of the certificate. By modifying the contents of the signature algorithm or the encoding of the signature, it is possible to change the certificate's fingerprint. This does not allow an attacker to forge certificates, and does not affect certificate verification or OpenSSL servers/clients in any other way. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint (e.g. certificate blacklists) may be affected. - CVE-2014-3570 (bignum squaring error) The BN_sqr implementation does not properly calculate the square of a BIGNUM value, which might make it easier for remote attackers to defeat cryptographic protection mechanisms via unspecified vectors, related to crypto/bn/asm/mips.pl, crypto/bn/asm/x86_64-gcc.c, and crypto/bn/bn_asm.c. Impact ====== A remote attacker is able to perform denial of service attacks, downgrade the cipher (effectively removing forward secrecy) or bypass certificate blacklists via various vectors. References ========== https://www.openssl.org/news/secadv_20150108.txt https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3571 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0206 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3569 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3572 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0204 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0205 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8275 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3570

1 0

[arch-security] CVE-2014
by G. Schlisio 09 Jan '15

09 Jan '15

Hi, i appreciate much the (not quite so) new security awareness of arch, since the beginning of last year. our main wiki site documenting the state of CVEs concerning Arch is named "CVE-2014" [0]. i think, this is a bit misleading, as i tend to think 2014 means the year, which is (fortunately|sadly) already passed. i see 3 ways to deal with this: • leave it, as is • create a new page named "CVE-2015" • rename CVE-2014 to something more generic (e.g. CVE, known CVEs …) i prefer solution 3, but i'd like to hear from others, especially the more involved, about their opinions. regards, georg [0] https://wiki.archlinux.org/index.php/CVE-2014

3 4

[arch-security] [ASA-201501-1] imagemagick: multiple issues
by Remi Gacogne 07 Jan '15

07 Jan '15

Arch Linux Security Advisory ASA-201501-1 ========================================= Severity: High Date : 2015-01-07 CVE-ID : Package : imagemagick Type : multiple issues Remote : No Link : https://wiki.archlinux.org/index.php/CVE-2014 Summary ======= The package imagemagick before version 6.9.0.3-1 is vulnerable to multiple issues, including denial of service and arbitrary code execution. Resolution ========== Upgrade to 6.9.0.3-1. # pacman -Syu "imagemagick>=6.9.0.3-1" The problem has been fixed upstream in version 6.9.0.3. Workaround ========== None. Description =========== Numerous vulnerabilities, including but not limited to buffer overflow, out-of-bound read, double-free and user-after-free have been fixed in imagemagick 6.9.0.2 and 6.9.0.3. Impact ====== An attacker allowed to supply a specially crafted image to imagemagick will be able to crash the process and execute arbitrary code. References ========== http://www.openwall.com/lists/oss-security/2014/12/24/1 http://osvdb.org/show/osvdb/116399 http://osvdb.org/show/osvdb/116397 http://osvdb.org/show/osvdb/116396 http://osvdb.org/show/osvdb/116395 http://osvdb.org/show/osvdb/116394 http://osvdb.org/show/osvdb/116394 http://osvdb.org/show/osvdb/116385 http://osvdb.org/show/osvdb/116389 http://osvdb.org/show/osvdb/116388 http://osvdb.org/show/osvdb/116386 http://osvdb.org/show/osvdb/116368 http://osvdb.org/show/osvdb/116359

1 0

[arch-security] Fw: [oss-security] Running Java across a privilege boundry
by Borja 05 Jan '15

05 Jan '15

Hi guys, I noticed that Arch's Java JRE binary is also prone to this issue: ----------------------------[ SNIP ]----------------------------- $ objdump -x /usr/lib/jvm/java-7-openjdk/jre/bin/java | grep RPATH | awk '{print $2}' | tr ':' '\n' $ORIGIN/../lib/amd64/jli bootstrap/jre/lib/amd64/jli $ORIGIN/../lib/amd64 bootstrap/lib/amd64 $ORIGIN/../jre/lib/amd64 bootstrap/jre/lib/amd64 $ $ $ mkdir -p bootstrap/lib/amd64/ $ touch bootstrap/lib/amd64/libc.so.6 $ $ $ sudo /usr/lib/jvm/java-7-openjdk/jre/bin/java /usr/lib/jvm/java-7-openjdk/jre/bin/java: error while loading shared libraries: bootstrap/lib/amd64/libc.so.6: file too short ----------------------------[ SNIP ]----------------------------- Below the oss-security mail by Tim Brown: --------------------------[ FORWARDED ]-------------------------- Fecha: Thu, 18 Dec 2014 09:18:25 +0000 Desde: Tim Brown <tmb(a)65535.com> Para: Solar Designer <solar(a)openwall.com> Cc: oss-security(a)lists.openwall.com Asunto: Re: [oss-security] Running Java across a privilege boundry On Wednesday 26 November 2014 03:54:48 Solar Designer wrote: > On Sun, Nov 23, 2014 at 05:59:41PM +0300, Solar Designer wrote: > > So far no distro has expressed any interest in having this embargoed. > > > > Distros list members: please speak up (here or on the distros list, with > > Tim CC'ed) if you'd like this embargoed. > > > > Tim: if until Tuesday no distro says they want this embargoed, please go > > ahead and make the issue fully public. (On a related note, I hate it > > when an issue is sort of "semi-public". It's the worst possible case. > > When this happens, it's a reason to opt for a shorter embargo period, or > > for none at all indeed.) If an embargo is requested, please make sure > > there's an exact date and time for the planned public disclosure. > > So far no distro has expressed any interest in having this embargoed, > and no specific coordinated disclosure date has been proposed by anyone. > Tim, please make the issue public now by posting it in here. Thanks! Apologies, I was locked in a server room for the last 2-3 weeks without access to my Internet. The issue for anyone that was interested was as follows: > $ objdump -x /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java | grep RPATH > > RPATH $ORIGIN/../lib/amd64/jli:bootstrap/jre/lib/amd64/jli: > $ORIGIN/../lib/amd64:bootstrap/lib/amd64: > $ORIGIN/../jre/lib/amd64:bootstrap/jre/lib/amd64 > $ mkdir -p bootstrap/jre/lib/amd64/jli > $ touch bootstrap/jre/lib/amd64/jli/libc.so.6 > $ sudo java > java: error while loading shared libraries: > bootstrap/jre/lib/amd64/jli/libc.so.6: file too short > > I haven't checked if this is an upstream problem or whether just Debian is > affected. > > Whilst strictly speaking, there is no security boundary offered by Java > itself, in the case of unsafe RPATH headers on a ELF binary, sudo can do > nothing to sanitise the environment. Nor indeed could an arbitrary setuid > which ends up calling Java with additional privileges. (Unlike say PATH > etc which sudo can quite happily sanitise.) > > As such, only fixing the java binary itself will prevent library injection > into any Java application that is run interactively (or maybe otherwise) > in such a manner. Cheers, Tim -- Tim Brown <mailto:tmb@65535.com> --------------------------[ FORWARDED ]-------------------------- Cheers, Borja. -- ================================================================================ GPG 0x8C00BA074CA6E08B -- https://www.libcrack.so/

1 0