- Arch-security - lists.archlinux.org

[arch-security] Heap overflow in Qemu USB stack
by Mark Lee 13 May '14

13 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, A red hat security member has posted information about a heap overflow in the qemu usb stack; please see below for forwarded message. Regards, Mark > Hello, > > Correct post load checks: > 1. dev->setup_len == sizeof(dev->data_buf) > seems fine, no need to fail migration > 2. When state is DATA, passing index > len > will cause memcpy with negative length, > resulting in heap overflow > > An user able to alter the saved VM data(either on the disk or over the wire during migration) could use this flaw to to corrupt QEMU process memory on the (destination) host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process. > > Upstream fix: > ------------- > -> http://article.gmane.org/gmane.comp.emulators.qemu/272322 > > Thank you. > -- > Prasad J Pandit / Red Hat Security Response Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNyVyAACgkQZ/Z80n6+J/bILQD/byjN4pCdSVMg6PEIfy91ZE/X 4dxLldlhpTLE6uXzpBMA+QHsVCfpm/wr0ZUyjjfmNqXkJkpGjjpAJtoj0cxdm+bl =Ya9G -----END PGP SIGNATURE-----

1 0

[arch-security] Kernel floppy ioctl kernel code execution
by Mark Lee 09 May '14

09 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, Usage of a floppy device can allow users to get root access in the Linux Kernel. Supposedly this has been posted to the Linux distros already, but I'm posting it here just in case. Regards, Mark > Hi, > > As this was posted to linux-distros, and was supposed to be made public > earlier this week, but so far wasn't published on oss-sec ... > > Reported by Matthew Daley to security(a)kernel.org. > > There apparently exists a proof of concept root exploit, that allows > local users with access to a floppy device to execute code in the linux > kernel. > > (I think this needs a floppy driver to actually allow access to a floppy > device. My machine only says "floppy0: no floppy controllers found" today.) > > Linux Kernel Mainline commits: > > 2145e15e0557a01b9195d1c7199a1b92cb9be81f > Author: Matthew Daley <mattd(a)bugfuzz.com> > Date: Mon Apr 28 19:05:21 2014 +1200 > > floppy: don't write kernel-only members to FDRAWCMD ioctl output > > Do not leak kernel-only floppy_raw_cmd structure members to userspace. > This includes the linked-list pointer and the pointer to the allocated > DMA space. > > Signed-off-by: Matthew Daley <mattd(a)bugfuzz.com> > References: CVE-2014-1738 > Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> > > commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c > Author: Matthew Daley <mattd(a)bugfuzz.com> > Date: Mon Apr 28 19:05:20 2014 +1200 > > floppy: ignore kernel-only members in FDRAWCMD ioctl input > > Always clear out these floppy_raw_cmd struct members after copying the > entire structure from userspace so that the in-kernel version is always > valid and never left in an interdeterminate state. > > Signed-off-by: Matthew Daley <mattd(a)bugfuzz.com> > References: CVE-2014-1737 > Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> > > Ciao, Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNsgSsACgkQZ/Z80n6+J/ZEugD+PQHpcvqb9vKhkZRpfBIEkC9c zJOaYQZ087dTZXZALIUBAIkxSbWuz+8vOowk/5OfcsySi+wu7afqwvuXDjKn78qO =UxRa -----END PGP SIGNATURE-----

1 0

[arch-security] [fish] multiple CVE's
by Billy McCann 06 May '14

06 May '14

The author of the fish shell will soon release version 2.2.1, which will fix vulnerabilities for CVE's CVE-2014-29{05,06,14} which affects versions 1.16.0-2.1.0. See the link to the bug report for the (copius) details. Link to bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1092091

2 1

[arch-security] CVE-2014-0196: Linux kernel pty layer race condition memory corruption
by Mark Lee 05 May '14

05 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, A race condition in the PTY write buffer handling has been discovered in the Linux kernel. See quoted text below and attachment for patch submitted by Jiri Slaby and Peter Hurley. Regards, Mark > Hi, > > SUSE customer Ericsson reported a kernel crash to us which turned out > to be a race condition in the PTY write buffer handling. > > When two processes/threads write to the same pty, the buffer end could > be overwritten and so memory corruption into adjacent buffers could lead > to crashes / code execution. > > Jiri Slaby and Peter Hurley localized and fixed this problem. > > CVE-2014-0196 has been assigned to this issue. > > Jiri thinks this was introduced during 2.6.31 development by > d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty > layer to use the normal buffering logic) in 2.6.31-rc3. Until then, pty > was writing directly to a line discipline without using buffers. > > https://bugzilla.novell.com/show_bug.cgi?id=875690 > > Patch is also attached. > > Ciao, Marcus > > > n_tty-Fix-n_tty_write-crash-when-echoing-in-raw-mode.patch > > From 34ba81cd3561c5fc6aff3041f3445d69f85b5155 Mon Sep 17 00:00:00 2001 > From: Peter Hurley <peter(a)hurleysoftware.com> > Date: Tue, 29 Apr 2014 12:38:36 -0400 > Subject: [PATCH 1/1] n_tty: Fix n_tty_write crash when echoing in raw mode > > The tty atomic_write_lock does not provide an exclusion guarantee for > the tty driver if the termios settings are LECHO & !OPOST. And since > it is unexpected and not allowed to call TTY buffer helpers like > tty_insert_flip_string concurrently, this may lead to crashes when > concurrect writers call pty_write. In that case the following two > writers: > * the ECHOing from a workqueue and > * pty_write from the process > race and can overflow the corresponding TTY buffer like follows. > > If we look into tty_insert_flip_string_fixed_flag, there is: > int space = __tty_buffer_request_room(port, goal, flags); > struct tty_buffer *tb = port->buf.tail; > ... > memcpy(char_buf_ptr(tb, tb->used), chars, space); > ... > tb->used += space; > > so the race of the two can result in something like this: > A B > __tty_buffer_request_room > __tty_buffer_request_room > memcpy(buf(tb->used), ...) > tb->used += space; > memcpy(buf(tb->used), ...) ->BOOM > > B's memcpy is past the tty_buffer due to the previous A's tb->used > increment. > > Since the N_TTY line discipline input processing can output > concurrently with a tty write, obtain the N_TTY ldisc output_lock to > serialize echo output with normal tty writes. This ensures the tty > buffer helper tty_insert_flip_string is not called concurrently and > everything is fine. > > Note that this is nicely reproducible by an ordinary user using > forkpty and some setup around that (raw termios + ECHO). And it is > exploitable in kernels at least after commit > d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to > use the normal buffering logic) in 2.6.31-rc3. > > js: add more info to the commit log > js: switch to bool > > Reported-and-tested-by: Jiri Slaby <jslaby(a)suse.cz> > Signed-off-by: Peter Hurley <peter(a)hurleysoftware.com> > Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> > Cc: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > --- > Hi security team, > > this is a fix for a potentially exploitable hole in the TTY layer. > linux-distros ML has been informed already (to the best of my > knowledge). > > We, at suse, would appreciate embargo till Mon May 5th. > > Thanks. > > drivers/tty/n_tty.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c > index 746ae80b972f..94101fc64e02 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -2353,10 +2353,18 @@ static ssize_t n_tty_write(struct tty_struct *tty, struct file *file, > if (tty->ops->flush_chars) > tty->ops->flush_chars(tty); > } else { > + struct n_tty_data *ldata = tty->disc_data; > + bool lock; > + > + lock = L_ECHO(tty) || (ldata->icanon && L_ECHONL(tty)); > + if (lock) > + mutex_lock(&ldata->output_lock); > while (nr > 0) { > c = tty->ops->write(tty, b, nr); > if (c < 0) { > retval = c; > + if (lock) > + mutex_unlock(&ldata->output_lock); > goto break_out; > } > if (!c) > @@ -2364,6 +2372,8 @@ static ssize_t n_tty_write(struct tty_struct *tty, struct file *file, > b += c; > nr -= c; > } > + if (lock) > + mutex_unlock(&ldata->output_lock); > } > if (!nr) > break; > -- 1.9.2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNn2+kACgkQZ/Z80n6+J/Z+VwD+NEmrct67a5k4ezgMFHYGQFRe OaBWcjPwO872ETeOVYQBAIPzEAYUXUz8142uw0xZmCfa43YjRHt8s5HMTBP8pFDe =kxZq -----END PGP SIGNATURE-----

1 0

[arch-security] OpenSSL NULL pointer dereference in do_ssl3_write
by Mark Lee 04 May '14

04 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all, Not sure if we're affected, but see below for email details. Regards, Mark > On 05/02/2014 09:30 AM, Marc Deslauriers wrote: >> Hello, >> >> A null pointer dereference bug was discovered in >> so_ssl3_write(). An attacker could possibly use this to cause >> OpenSSL to crash, resulting in a denial of service. >> >> http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3321 >> >> >> >> http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=e76e… >> >> >> http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/005_openssl.patch.sig >> >> >> Could a CVE please be assigned to this issue? >> >> Thanks, >> >> Marc. >> > > I think getting this one a CVE is time critical. Mitre: sorry if > this causes a duplicate, but I'm assigning a CVE now. Please use > CVE-2014-0198 for this issue. Also cc'ing Theo so OpenBSD gets > notified for sure. Speaking of which Theo: should we get you or an > OpenBSD deputy (Bob Beck?) onto distros@? > > -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: > 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNj4/kACgkQZ/Z80n6+J/ZsowD+K/0ctwnVZwrFY37G8aUaSBXf th2NoIQeFiR/fp1ean0A/1Ik5c/tCHMBR6dv+uJD+F8wSgGAoCAh/einDFlgfZjS =QeNS -----END PGP SIGNATURE-----

2 2

[arch-security] [linux] CVE-2014-2739 :: cma_req_handler function in drivers/infiniband/core/cma.c
by Billy McCann 02 May '14

02 May '14

Not sure if this one applies to Arch. I'll put this here for those in the know. CVE-2014-2729 :: [linux] The cma_req_handler function in drivers/infiniband/core/cma.c in the Linux kernel 3.14.x through 3.14.1 attempts to resolve an RDMA over Converged Ethernet (aka RoCE) address that is properly resolved within a different module, which allows remote attackers to cause a denial of service (incorrect pointer dereference and system crash) via crafted network traffic. INFO: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2739 https://bugzilla.redhat.com/show_bug.cgi?id=1085415 UPSTREAM FIX: https://patchwork.kernel.org/patch/3896781/

1 0

[arch-security] PHP CVE-2014-0185
by Pierre Schmitz 01 May '14

01 May '14

Hi all, just to let you know, Arch was not affected by CVE-2014-0185 as I always patched the default config of FPM. (Unless users decided to change the default config) Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

1 0

[arch-security] Linux: CVE-2014-2851
by Timothée Ravier 13 Apr '14

13 Apr '14

Hi, We might be affected by this one, but I don't have the time to check right now: * Report: http://seclists.org/oss-sec/2014/q2/97 * Patch: https://lkml.org/lkml/2014/4/10/736 * Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1086730 -- Timothée Ravier

1 1

[arch-security] Openssl flaw
by Plonky Duby 08 Apr '14

08 Apr '14

http://www.openssl.org/news/secadv_20140407.txt We should patch and repack Regards !

4 11

[arch-security] [kernel] CVE-2014-2568 net: potential information leak when ubuf backed skbs are skb_zerocopy()ied
by Billy McCann 21 Mar '14

21 Mar '14

[linux] CVE-2014-2568 net: potential information leak when ubuf backed skbs are skb_zerocopy()ied Description " An information leak flaw was found in the way skb_zerocopy() copied skbs that are backed by userspace buffers (for example vhost-net and recent xen netback). Once the source skb is consumed, ubuf destructor is called and potentially releases the corresponding userspace buffers, which can then for example be repurposed, while the destination skb is still pointing to the them. " MITRE assignment http://seclists.org/oss-sec/2014/q1/630 Upstream Patch https://lkml.org/lkml/2014/3/20/421 Bug Report https://bugs.archlinux.org/task/39566 Patch attached to bug report

1 0