Re: rpcbomb: remote rpcbind denial-of-service

[Florian Weimer <fweimer () redhat com>]

On 05/07/2017 08:47 PM, Salvatore Bonaccorso wrote:
> Hi
>
> On Fri, May 05, 2017 at 11:52:49AM +0200, Florian Weimer wrote:
> > On 05/05/2017 11:22 AM, Marcus Meissner wrote:
> > > On Wed, May 03, 2017 at 05:55:20PM -0700, Seth Arnold wrote:
> > > > On Wed, May 03, 2017 at 08:55:23PM +0200, Guido Vranken wrote:
> > > > > This vulnerability allows an attacker to allocate any amount of bytes
> > > > > (up to 4 gigabytes per attack) on a remote rpcbind host, and the
> > > > > memory is never freed unless the process crashes or the administrator
> > > > > halts or restarts the rpcbind service.
> > > > > [...]
> > > > > An extensive write-up can be found here:
> > > > > https://guidovranken.wordpress.com/2017/05/03/rpcbomb-remote-rpcbind-denial-of-service-patches/
> > > > >
> > > > > Exploit + patches: https://github.com/guidovranken/rpcbomb/
> > > >
> > > > Hello Guido, nice find. Have CVE numbers been requested for this issue
> > > > yet? Have you investigated if ntirpc is affected too? Much of the code
> > > > looks similar:
> > > >
> > > > http://sources.debian.net/src/ntirpc/1.4.3-3/src/rpc_generic.c/#L728
> > >
> > > We also saw glibc affected.
> > >
> > > https://bugzilla.suse.com/show_bug.cgi?id=1037559#c7
> > >
> > > That said, your reproducer allocates virtual memory, and on systems with overcommit
> > > there is only neglible impact on overall memory pressure.
> > >
> > > The rpc service will however likely crash at some point though when there is no virtual
> > > address space left for it.
> >
> > Thanks, I filed it upstream as well:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21461
> >
> > Looks like both xdr_bytes and xdr_string have a similar bug.
> >
> > I'd appreciate some guidance on reusing or not reusing CVE IDs here.
>
> A separate CVE should be used for this issue as clarified with MITRE.
>
> It was assigned CVE-2017-8804.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21461
>
> Patch posted at
> https://sourceware.org/ml/libc-alpha/2017-05/msg00105.html by Florian
> Weimer.

Note that we have a bit of a dispute here whether whether this is 
actually a vulnerability in the XDR code, or whether the caller is to blame.

Thanks,
Florian