All of lore.kernel.org
 help / color / mirror / Atom feed
From: akuster808 <akuster808@gmail.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] rpcbind: Security Advisory - rpcbind - CVE-2015-7236
Date: Tue, 17 Nov 2015 17:44:53 -0800	[thread overview]
Message-ID: <564BD815.2090204@gmail.com> (raw)
In-Reply-To: <1447744712-18615-1-git-send-email-wenzong.fan@windriver.com>

Li Zhou,

Can we get the CVE mentioned in the patch or rename the the patch to
include the CVE #.

regards,
Armin

On 11/16/2015 11:18 PM, wenzong.fan@windriver.com wrote:
> From: Li Zhou <li.zhou@windriver.com>
> 
> rpcbind: Fix memory corruption in PMAP_CALLIT code
> 
> Use-after-free vulnerability in xprt_set_caller in rpcb_svc_com.c in
> rpcbind 0.2.1 and earlier allows remote attackers to cause a denial of
> service (daemon crash) via crafted packets, involving a PMAP_CALLIT
> code.
> 
> The patch comes from
> <http://www.openwall.com/lists/oss-security/2015/09/18/7>, and it hasn't
> been in rpcbind upstream yet.
> 
> Signed-off-by: Li Zhou <li.zhou@windriver.com>
> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
> ---
>  ...Fix_memory_corruption_in_PMAP_CALLIT_code.patch | 83 ++++++++++++++++++++++
>  meta/recipes-extended/rpcbind/rpcbind_0.2.3.bb     |  1 +
>  2 files changed, 84 insertions(+)
>  create mode 100644 meta/recipes-extended/rpcbind/rpcbind/rpcbind_Fix_memory_corruption_in_PMAP_CALLIT_code.patch
> 
> diff --git a/meta/recipes-extended/rpcbind/rpcbind/rpcbind_Fix_memory_corruption_in_PMAP_CALLIT_code.patch b/meta/recipes-extended/rpcbind/rpcbind/rpcbind_Fix_memory_corruption_in_PMAP_CALLIT_code.patch
> new file mode 100644
> index 0000000..f156290
> --- /dev/null
> +++ b/meta/recipes-extended/rpcbind/rpcbind/rpcbind_Fix_memory_corruption_in_PMAP_CALLIT_code.patch
> @@ -0,0 +1,83 @@
> +commit 06f7ebb1dade2f0dbf872ea2bedf17cff4734bdd
> +Author: Olaf Kirch <okir@...e.de>
> +Date:   Thu Aug 6 16:27:20 2015 +0200
> +
> +    Fix memory corruption in PMAP_CALLIT code
> +    
> +     - A PMAP_CALLIT call comes in on IPv4 UDP
> +     - rpcbind duplicates the caller's address to a netbuf and stores it in
> +       FINFO[0].caller_addr. caller_addr->buf now points to a memory region A
> +       with a size of 16 bytes
> +     - rpcbind forwards the call to the local service, receives a reply
> +     - when processing the reply, it does this in xprt_set_caller:
> +         xprt->xp_rtaddr = *FINFO[0].caller_addr
> +       It sends out the reply, and then frees the netbuf caller_addr and
> +       caller_addr.buf.
> +       However, it does not clear xp_rtaddr, so xp_rtaddr.buf now refers
> +       to memory region A, which is free.
> +     - When the next call comes in on the UDP/IPv4 socket, svc_dg_recv will
> +       be called, which will set xp_rtaddr to the client's address.
> +       It will reuse the buffer inside xp_rtaddr, ie it will write a
> +       sockaddr_in to region A
> +    
> +    Some time down the road, an incoming TCP connection is accepted,
> +    allocating a fresh SVCXPRT. The memory region A is inside the
> +    new SVCXPRT
> +    
> +     - While processing the TCP call, another UDP call comes in, again
> +       overwriting region A with the client's address
> +     - TCP client closes connection. In svc_destroy, we now trip over
> +       the garbage left in region A
> +    
> +    We ran into the case where a commercial scanner was triggering
> +    occasional rpcbind segfaults. The core file that was captured showed
> +    a corrupted xprt->xp_netid pointer that was really a sockaddr_in.
> +    
> +    Signed-off-by: Olaf Kirch <okir@...e.de>
> +
> +    Upstream-Status: Backport
> +
> +    Signed-off-by: Li Zhou <li.zhou@windriver.com>
> +---
> + src/rpcb_svc_com.c |   23 ++++++++++++++++++++++-
> + 1 file changed, 22 insertions(+), 1 deletion(-)
> +
> +Index: rpcbind-0.1.6+git20080930/src/rpcb_svc_com.c
> +===================================================================
> +--- rpcbind-0.1.6+git20080930.orig/src/rpcb_svc_com.c
> ++++ rpcbind-0.1.6+git20080930/src/rpcb_svc_com.c
> +@@ -1298,12 +1298,33 @@ check_rmtcalls(struct pollfd *pfds, int
> + 	return (ncallbacks_found);
> + }
> + 
> ++/*
> ++ * This is really a helper function defined in libtirpc, but unfortunately, it hasn't
> ++ * been exported yet.
> ++ */
> ++static struct netbuf *
> ++__rpc_set_netbuf(struct netbuf *nb, const void *ptr, size_t len)
> ++{
> ++	if (nb->len != len) {
> ++		if (nb->len)
> ++			mem_free(nb->buf, nb->len);
> ++		nb->buf = mem_alloc(len);
> ++		if (nb->buf == NULL)
> ++			return NULL;
> ++
> ++		nb->maxlen = nb->len = len;
> ++	}
> ++	memcpy(nb->buf, ptr, len);
> ++	return nb;
> ++}
> ++
> + static void
> + xprt_set_caller(SVCXPRT *xprt, struct finfo *fi)
> + {
> ++	const struct netbuf *caller = fi->caller_addr;
> + 	u_int32_t *xidp;
> + 
> +-	*(svc_getrpccaller(xprt)) = *(fi->caller_addr);
> ++	__rpc_set_netbuf(svc_getrpccaller(xprt), caller->buf, caller->len);
> + 	xidp = __rpcb_get_dg_xidp(xprt);
> + 	*xidp = fi->caller_xid;
> + }
> diff --git a/meta/recipes-extended/rpcbind/rpcbind_0.2.3.bb b/meta/recipes-extended/rpcbind/rpcbind_0.2.3.bb
> index 237018b..9b1c650 100644
> --- a/meta/recipes-extended/rpcbind/rpcbind_0.2.3.bb
> +++ b/meta/recipes-extended/rpcbind/rpcbind_0.2.3.bb
> @@ -19,6 +19,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/rpcbind/rpcbind-${PV}.tar.bz2 \
>             file://rpcbind.conf \
>             file://rpcbind.socket \
>             file://rpcbind.service \
> +           file://rpcbind_Fix_memory_corruption_in_PMAP_CALLIT_code.patch \
>            "
>  MUSLPATCHES_libc-musl = "file://musl-sunrpc.patch"
>  
> 


  reply	other threads:[~2015-11-18  1:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17  7:18 [PATCH] rpcbind: Security Advisory - rpcbind - CVE-2015-7236 wenzong.fan
2015-11-18  1:44 ` akuster808 [this message]
2015-11-18 22:50   ` Burton, Ross
2015-11-25  3:58     ` akuster808

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564BD815.2090204@gmail.com \
    --to=akuster808@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.