June 2014 - Arch-security - lists.archlinux.org

[arch-security] How to properly report vulnerabilities
by Karol Blazewicz 08 Jul '14

08 Jul '14

Should I open a bug report saying that e.g. some Arch package has certain vulnerability, mark the report as critical and wait for someone to set it as private? How do we deal with such sensitive information? I've looked in the wiki, but neither https://wiki.archlinux.org/index.php/Arch_CVE_Monitoring_Team nor https://wiki.archlinux.org/index.php/CVE-2014 has any info on this.

4 7

[arch-security] sctp:sk_ack_backlog wrap-around problem
by Mark Lee 27 Jun '14

27 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Salutations, To all, please see below for cve request on oss-security. Regards, Mark > Description of the problem: > For a TCP-style socket, while processing the COOKIE_ECHO chunk in > sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, a > new association would be created in sctp_unpack_cookie(), but > afterwards, some processing maybe failed, and sctp_association_free() > will be called to free the previously allocated association, in > sctp_association_free(), sk_ack_backlog value is decremented for this > socket, since the initial value for sk_ack_backlog is 0, after > the decrement, it will be 65535, a wrap-around problem happens, and > if we want to establish new associations afterward in the same > socket, ABORT would be triggered since sctp deem the accept queue as > full. > > A remote attacker can block further connection to the particular sctp > server socket by sending a specially crafted sctp packet. > > Upstream patch: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=… > > References: > https://bugzilla.redhat.com/show_bug.cgi?id=1113967 > > Thanks, > -- Petr Matousek / Red Hat Product Security PGP: 0xC44977CA 8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlOtv1QACgkQZ/Z80n6+J/aYmwD9GzejDSu/l41OV5dgIes8Xy7C Vr3zSrDFm1/M0Ur+yUUA/RgT1i8XfMefZrxXf8Mz50QyDEZDL94/h3TzNKdntQka =WrWf -----END PGP SIGNATURE-----

1 0

[arch-security] GnuPG < 2.0.24 DoS (CVE-2014-4617)
by Remi Gacogne 26 Jun '14

26 Jun '14

Hi all, A security issue has been reported to oss-security [1] regarding a denial of service in GnuPG < 2.0.24. Please see the original message posted to oss-security or the GnuPG announcement [2] for additional information. The GnuPG package in Arch Linux is currently in version 2.0.23 and therefore seems to be vulnerable. It has already been flagged as out-of-date but has not been updated yet. [1] http://www.openwall.com/lists/oss-security/2014/06/24/1 [2] http://lists.gnupg.org/pipermail/gnupg-announce/2014q2/000345.html Best regards, Remi

3 3

[arch-security] Subscription to OSS-security linux-distros
by Mark Lee 12 Jun '14

12 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, Is anyone subscribed to the Linux-distros mailing list of OSS-security? From, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOQnGMACgkQZ/Z80n6+J/alAwD/V2XnytW/x8gOcltGQ8T39Jmb Cb6H4l3Ej6n8U3zWI/sA/2uekN8yAEvghpAoe0SW39fWz3H+Cy0GUKZAVe1J7mKH =fFN9 -----END PGP SIGNATURE-----

4 6

[arch-security] D-Bus < 1.8.4 (CVE-2014-3477) security issue (DoS, possible side-channel communication)
by Remi Gacogne 11 Jun '14

11 Jun '14

Hi all, A security issue has been reported to oss-security [1] regarding D-Bus < 1.8.4, allowing denial of service or, under certain conditions, side-channel communication between processes that should not be able to communicate. Please see the original post to oss-security below for additional information. This vulnerability has been assigned CVE-2014-3477. The D-Bus package in Arch Linux is currently in version 1.8.2 and therefore seems to be vulnerable. It has already been flagged as out-of-date but does not appear to have been updated yet. [1] http://marc.info/?l=oss-security&m=140242136131355&w=2 Regards, Remi > D-Bus <http://www.freedesktop.org/wiki/Software/dbus/> is an > asynchronous inter-process communication system, commonly used > for system services or within a desktop session on Linux and other > operating systems. > > Alban Crequy at Collabora Ltd. discovered and fixed a denial-of-service > flaw in dbus-daemon, part of the reference implementation of D-Bus. > Additionally, in highly unusual environments the same flaw could lead to > a side channel between processes that should not be able to communicate. > > On the stable branch, this is fixed in version 1.8.4: > http://dbus.freedesktop.org/releases/dbus/dbus-1.8.4.tar.gz > http://dbus.freedesktop.org/releases/dbus/dbus-1.8.4.tar.gz.asc > > On the previous stable branch, this is fixed in version 1.6.20: > http://dbus.freedesktop.org/releases/dbus/dbus-1.6.20.tar.gz > http://dbus.freedesktop.org/releases/dbus/dbus-1.6.20.tar.gz.asc > > Distributions supporting other versions should base their changes on > this commit: > http://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.8&id=24c590703ca47eb… > > Summary: > > If a client C1 is prohibited from sending a message to a service S1, and > S1 is not currently running, then C1 can attempt to send a message to > S1's well-known bus name, causing dbus-daemon to start S1 [1]. When S1 > has started and obtained its well-known bus name, the dbus-daemon > evaluates its security policy, decides that it will not deliver the > message to S1, and constructs an AccessDenied error. However, instead of > sending that AccessDenied error reply to C1 as a reply to the denied > message, dbus-daemon incorrectly sends it to S1 as a reply to the > request to obtain its well-known bus name. > > Impact A: denial of service. S1 will fail to initialize, and exit, > denying service to legitimate clients of S1. > > Impact B: side channel. In environments where C1 and S1 are untrusted > and are administratively prohibited from communicating, S1 could also > use these incorrectly-directed error messages as a side channel to > receive information from C1. > > Mitigations: > > Impact A: if a legitimate client was actively using S1, S1 would already > have been started, so C1 can only deny service to a legitimate client > that only recently became active. > > Impact B: in practice processes sharing a system bus can typically > communicate in other ways (non-D-Bus IPC mechanisms, files in /tmp, > etc.), so impact B is not relevant on normal systems. It might be > relevant on systems when an LSM such as SELinux is used in a highly > restrictive configuration.

1 0

[arch-security] Linux kernel futex local privilege escalation (CVE-2014-3153)
by Manuel Reimer 06 Jun '14

06 Jun '14

Hello, the kernel, again, has a local privilege escalation bug. See: http://seclists.org/oss-sec/2014/q2/467 <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e…> Maybe it's a good idea to ship a patched kernel? Greetings, Manuel Reimer

1 0

[arch-security] several openssl-cve's
by G. Schlisio 05 Jun '14

05 Jun '14

there have been multiple cve's [0] that are fixed in the latest openssh 1.0.1h, which is already in the repos since a few hours. is it worth writing into the wiki? [0] http://www.openssl.org/news/secadv_20140605.txt

2 1