On Wed, Nov 05, 2014 at 09:21:37PM +0100, [email protected] wrote:
> Hello,
>
> I'm sending a small set of 3 patches for a problem, that I have
> reported a few weeks ago.
> rpc.mountd can be blocked by a bad client, that sends lots of
> RPC requests, but never reads the replies from the socket either
> intentionally or e.g. caused by a wrong configured MTU.
>
> While looking for a possible solution, I found another weakness
> in rpc.mountd if it is used "multithreaded" (-t nn).
>
> The first two patches fix that weakness in the case of !HAVE_LIBTIRPC
> and HAVE_LIBTIRPC.
They look fine to me.
> The third patch more a kind of suggestion how the main problem could
> be fixed.
Sounds reasonable to me.
> I don't know whether we can set MAXREC without causing
> new troubles. When this patch is used, a further patch for libtirpc
> also should be used. You can find it here:
> http://sourceforge.net/p/libtirpc/mailman/libtirpc-devel/?viewmonth=201409
So applying this last patch and then building against an unpatched
libtirpc would expose us to a serious bug? Do we need to do something
to make that less likely to happen?
--b.
>
> Best regards,
> Bodo
> -----Original Message-----
> From: J. Bruce Fields [mailto:[email protected]]
> Sent: Wednesday, November 05, 2014 10:06 PM
> To: Str?sser, Bodo
> Cc: [email protected]; [email protected]
> Subject: Re: [nfs-utils] [PATCH 0/3] rpc.mountd: fix some vulnerabilities
>
> On Wed, Nov 05, 2014 at 09:21:37PM +0100, [email protected] wrote:
> > Hello,
> >
> > I'm sending a small set of 3 patches for a problem, that I have
> > reported a few weeks ago.
> > rpc.mountd can be blocked by a bad client, that sends lots of
> > RPC requests, but never reads the replies from the socket either
> > intentionally or e.g. caused by a wrong configured MTU.
> >
> > While looking for a possible solution, I found another weakness
> > in rpc.mountd if it is used "multithreaded" (-t nn).
> >
> > The first two patches fix that weakness in the case of !HAVE_LIBTIRPC
> > and HAVE_LIBTIRPC.
>
> They look fine to me.
>
> > The third patch more a kind of suggestion how the main problem could
> > be fixed.
>
> Sounds reasonable to me.
>
> > I don't know whether we can set MAXREC without causing
> > new troubles. When this patch is used, a further patch for libtirpc
> > also should be used. You can find it here:
> > http://sourceforge.net/p/libtirpc/mailman/libtirpc-devel/?viewmonth=201409
>
> So applying this last patch and then building against an unpatched
> libtirpc would expose us to a serious bug? Do we need to do something
> to make that less likely to happen?
The bug in libtirpc is triggered, if the write() to the socket returns -EAGAIN
but one of the many retries in the following 2 seconds succeeds. Then the
normal reply is sent with a prefix of (maybe many) bytes from rpc.mountd's
memory space before the reply buffer. That means, that some data from memory is
sent (authentication data?) or rpc.mountd might get SIGSEGV, I don't know.
But I think it won't be easy to trigger this. rpcbind uses the nonblocking mode
of libtirpc and no one complains about the bug in libtirpc.
Anyway, it of course would be better to use a fixed libtirpc, as I can't see a
way to have a work around in rpc.mountd for the libtirpc bug.
Bodo
>
> --b.
>
> >
> > Best regards,
> > Bodo