From: Chuck Lever <chuck.lever@oracle.com>
To: Guillem Jover <guillem@debian.org>
Cc: linux-nfs@vger.kernel.org, 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Thu, 03 Jun 2010 16:34:01 -0400 [thread overview]
Message-ID: <4C0811B9.3060809@oracle.com> (raw)
In-Reply-To: <20100603202743.GA6643-v62vTE6/wQGgM1MOaoewpti2O/JbrIOy@public.gmane.org>
On 06/ 3/10 04:27 PM, Guillem Jover wrote:
> Hi!
>
> On Thu, 2010-06-03 at 16:07:50 -0400, Chuck Lever wrote:
>> On 06/ 2/10 07:25 AM, An=C3=ADbal Monsalve Salazar wrote:
>>> On Tue, Jun 01, 2010 at 02:09:07PM +0200, Guillem Jover wrote:
>>>> On Thu, 2010-05-27 at 19:09:08 +0200, Guillem Jover wrote:
>>>>> Package: rpcbind
>>>>> Version: 0.2.0-4
>>>>> Severity: serious
>>>>> Tags: security
>>>>
>>>>> The rpcbind daemon, which runs as root, uses /tmp/portmap.xdr and
>>>>> /tmp/rpcbind.xdr for doing warm starts as what seems to be a way =
to
>>>>> preserve state between invokations. It parses (through libtirpc) =
and
>>>>> removes them on start. It creates them before exiting.
>>>>>
>>>>> So first off, *any* user can craft those two files before the dae=
mon
>>>>> has started for the first time, which the daemon will parse. This
>>>>> might be ok, depending on the checks done on parse, I'd still be =
very
>>>>> wary of letting a user be able to craft such files at will.
>>>>
>>>> It seems to be doing no checks whatsoever. A simple test I perform=
ed at
>>>> the time of filing this report, but didn't seem to have any obviou=
s
>>>> consequence, shows this which I noticed later on:
>
>>> The original bug report is at http://bugs.debian.org/583435
>
> I'm adding here part of the initial mail that I trimmed when replying
> to myself:
>
> ,---
> The second problem is that those files get created by the daemon on
> shutdown, and they *do* follow symlinks. So a user can drop two
> symlinks
> there while the daemon is running and overwrite any file on the file
> system on shutdown.
>
> The fix would consist of passing to configure something like
> =E2=80=9C--with-statedir=3D/var/cache/rpcbind=E2=80=9D, and make sure=
the daemon creates
> such directory if missing on exit in src/warmstart.c:write_struct(),
> which it does not seem to be doing currently.
>
> In addition it would be wise to notify upstream to change the default
> statedir to something else than /tmp.
> `---
Agree changing the upstream default is a good idea.
Generally, that kind of directory is created as part of installation=20
(like, by rpm --install) rather than by the daemon itself.
>> Would /var/run (or a subdirectory of it) be a better choice than /tm=
p ?
>
> /var/run might not be preserved across reboots, but regardless of tha=
t I
> think /var/cache is a better fit, it's internal state, but it's used
> to speed up start up time, and can be removed w/o ill effects.
No, it's not intended to speed start up.
The cache files aren't really supposed to be retained over a reboot.=20
After a system restart, all of the RPC services will restart and=20
register themselves again. If just rpcbind restarts, all that=20
registration state is lost, so that's the point of saving it in a file.
I don't have a preference wrt /var/run or /var/cache.
next prev parent reply other threads:[~2010-06-03 20:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100527170908.GA14298@gaara.hadrons.org>
[not found] ` <20100601120907.GA23357@gaara.hadrons.org>
2010-06-02 11:25 ` Bug#583435: rpcbind: Insecure handling of state files Aníbal Monsalve Salazar
[not found] ` <20100602112520.GA22639-q3oZDYqQg6zyUObV3Cmqeti2O/JbrIOy@public.gmane.org>
2010-06-03 20:07 ` Chuck Lever
2010-06-03 20:27 ` Guillem Jover
[not found] ` <20100603202743.GA6643-v62vTE6/wQGgM1MOaoewpti2O/JbrIOy@public.gmane.org>
2010-06-03 20:34 ` Chuck Lever [this message]
2010-06-03 21:07 ` Guillem Jover
[not found] ` <20100603210707.GA7377-v62vTE6/wQGgM1MOaoewpti2O/JbrIOy@public.gmane.org>
2010-06-03 21:11 ` Chuck Lever
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=4C0811B9.3060809@oracle.com \
--to=chuck.lever@oracle.com \
--cc=583435@bugs.debian.org \
--cc=guillem@debian.org \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).