- Arch-security - lists.archlinux.org

[arch-security] Idea : Automated emails to
by Billy McCann 17 May '14

17 May '14

Greetings all. I have a concept which I'd like to run by you all. Typically, new releases are issued by upstream to address them. However, there are times where the package is patched prior to the new release. Of course, this is great work by the devs. Myself, I'd like to document that the CVE's have been addressed on the CVE-2014 wiki page. I'm sure the devs don't have time to enter the CVE entries onto the wiki page themselves; after all, this is why the CVE Monitoring Team was assembled. I'd be happy to enter them myself. I'm wondering if there is a mechanism by which a patch could be marked as addressing a CVE. And once it is marked as addressing a CVE, is there any mechanism which could be made to automatically send an email to arch-security announcing this? A one line email stating the package name and the CVE number would be enough for me to collect any information and add the entry to the CVE-2014 wiki page. If I were more familiar with the process, I would be happy to write such a script myself. Should someone in the know point in the right direction, I'll take the initiative and begin the process. - bwayne

1 2

[arch-security] libXfont - multiple CVE's
by Billy McCann 17 May '14

17 May '14

libXfont 1.4.8 has been released to address the following: CVE-2014-0209 CVE-2014-0210 CVE-2014-0211 Solution: Update libXfont to 1.4.8 https://bugs.archlinux.org/task/40409 Details: http://seclists.org/oss-sec/2014/q2/302 "" - CVE-2014-0209: integer overflow of allocations in font metadata file parsing When a local user who is already authenticated to the X server adds a new directory to the font path, the X server calls libXfont to open the fonts.dir and fonts.alias files in that directory and add entries to the font tables for every line in it. A large file (~2-4 gb) could cause the allocations to overflow, and allow the remaining data read from the file to overwrite other memory in the heap. Affected functions: FontFileAddEntry(), lexAlias() - CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies When parsing replies received from the font server, these calls do not check that the lengths and/or indexes returned by the font server are within the size of the reply or the bounds of the memory allocated to store the data, so could write past the bounds of allocated memory when storing the returned data. Affected functions: _fs_recv_conn_setup(), fs_read_open_font(), fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(), fs_read_list(), fs_read_list_info() - CVE-2014-0211: integer overflows calculating memory needs for xfs replies These calls do not check that their calculations for how much memory is needed to handle the returned data have not overflowed, so can result in allocating too little memory and then writing the returned data past the end of the allocated buffer. Affected functions: fs_get_reply(), fs_alloc_glyphs(), fs_read_extent_info() ""

2 1

[arch-security] Linux 3.14.3 (CVE-2014-0196)
by Xan 14 May '14

14 May '14

Hi, To everyone: this [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0196] affects us? Thanks, Xan.

6 6

[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