Debian Bug report logs - #583435
CVE-2010-2061 rpcbind: Insecure handling of state files

version graph

Package: rpcbind; Maintainer for rpcbind is Anibal Monsalve Salazar <anibal@debian.org>; Source for rpcbind is src:rpcbind.

Reported by: Guillem Jover <guillem@debian.org>

Date: Thu, 27 May 2010 17:12:02 UTC

Severity: serious

Tags: security

Found in version rpcbind/0.2.0-4

Fixed in version rpcbind/0.2.0-4.1

Done: Stefan Fritsch <sf@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 27 May 2010 17:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
New Bug report received and forwarded. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 27 May 2010 17:12:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: submit@bugs.debian.org
Subject: rpcbind: Insecure handling of state files
Date: Thu, 27 May 2010 19:09:08 +0200
Package: rpcbind
Version: 0.2.0-4
Severity: serious
Tags: security

Hi!

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 daemon
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.

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
“--with-statedir=/var/cache/rpcbind”, 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.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Tue, 01 Jun 2010 12:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Tue, 01 Jun 2010 12:18:03 GMT) Full text and rfc822 format available.

Message #10 received at 583435@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Tue, 1 Jun 2010 14:09:07 +0200
Hi!

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 daemon
> 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 performed at
the time of filing this report, but didn't seem to have any obvious
consequence, shows this which I noticed later on:

,---
gaara:~# /etc/init.d/rpcbind start
Starting rpcbind daemon....
gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     23424  0.0  0.0  18768   704 ?        Ss   13:53   0:00 /sbin/rpcbind -w
gaara:~# /etc/init.d/rpcbind stop
Stopping rpcbind daemon....
gaara:~# dd if=/dev/urandom of=/tmp/rpcbind.xdr bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1,0 kB) copied, 0,000861307 s, 1,2 MB/s
gaara:~# /etc/init.d/rpcbind start
Starting rpcbind daemon....
gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     23440  0.0  0.0 4008972  772 ?        Ss   13:54   0:00 /sbin/rpcbind -w
`---

The first start is a normal clean invokation, the second one is using
the crafted file. See how it has allocated almost 4 GiB. Disregard though,
me running all this as root, a user would be able to craft those files as
long as they were not already in /tmp.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Wed, 02 Jun 2010 11:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aníbal Monsalve Salazar <anibal@debian.org>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Wed, 02 Jun 2010 11:27:03 GMT) Full text and rfc822 format available.

Message #15 received at 583435@bugs.debian.org (full text, mbox):

From: Aníbal Monsalve Salazar <anibal@debian.org>
To: linux-nfs@vger.kernel.org
Cc: Guillem Jover <guillem@debian.org>, 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Wed, 2 Jun 2010 21:25:21 +1000
On Tue, Jun 01, 2010 at 02:09:07PM +0200, Guillem Jover wrote:
>Hi!
>
>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 daemon
>>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 performed at
>the time of filing this report, but didn't seem to have any obvious
>consequence, shows this which I noticed later on:
>
>,---
>gaara:~# /etc/init.d/rpcbind start
>Starting rpcbind daemon....
>gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
>USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>root     23424  0.0  0.0  18768   704 ?        Ss   13:53   0:00 /sbin/rpcbind -w
>gaara:~# /etc/init.d/rpcbind stop
>Stopping rpcbind daemon....
>gaara:~# dd if=/dev/urandom of=/tmp/rpcbind.xdr bs=1024 count=1
>1+0 records in
>1+0 records out
>1024 bytes (1,0 kB) copied, 0,000861307 s, 1,2 MB/s
>gaara:~# /etc/init.d/rpcbind start
>Starting rpcbind daemon....
>gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
>USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>root     23440  0.0  0.0 4008972  772 ?        Ss   13:54   0:00 /sbin/rpcbind -w
>`---
>
>The first start is a normal clean invokation, the second one is using
>the crafted file. See how it has allocated almost 4 GiB. Disregard though,
>me running all this as root, a user would be able to craft those files as
>long as they were not already in /tmp.
>
>thanks,
>guillem

I'm sending this bug report to the linux-nfs mailing list.

The original bug report is at http://bugs.debian.org/583435

Thank you.




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 03 Jun 2010 20:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 03 Jun 2010 20:30:07 GMT) Full text and rfc822 format available.

Message #20 received at 583435@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Thu, 3 Jun 2010 22:27:43 +0200
Hi!

On Thu, 2010-06-03 at 16:07:50 -0400, Chuck Lever wrote:
> On 06/ 2/10 07:25 AM, Aníbal 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 daemon
> > > > 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 performed at
> > > the time of filing this report, but didn't seem to have any obvious
> > > 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
“--with-statedir=/var/cache/rpcbind”, 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.
`---

> Would /var/run (or a subdirectory of it) be a better choice than /tmp ?

/var/run might not be preserved across reboots, but regardless of that 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.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 03 Jun 2010 20:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chuck Lever <chuck.lever@oracle.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 03 Jun 2010 20:39:08 GMT) Full text and rfc822 format available.

Message #25 received at 583435@bugs.debian.org (full text, mbox):

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
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íbal 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 daemon
>>>>> 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 performed at
>>>> the time of filing this report, but didn't seem to have any obvious
>>>> 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
> “--with-statedir=/var/cache/rpcbind”, 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 
(like, by rpm --install) rather than by the daemon itself.

>> Would /var/run (or a subdirectory of it) be a better choice than /tmp ?
>
> /var/run might not be preserved across reboots, but regardless of that 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. 
After a system restart, all of the RPC services will restart and 
register themselves again.  If just rpcbind restarts, all that 
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.




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 03 Jun 2010 21:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 03 Jun 2010 21:09:03 GMT) Full text and rfc822 format available.

Message #30 received at 583435@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Thu, 3 Jun 2010 23:07:07 +0200
On Thu, 2010-06-03 at 16:34:01 -0400, Chuck Lever wrote:
> On 06/ 3/10 04:27 PM, Guillem Jover wrote:
> >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
> >“--with-statedir=/var/cache/rpcbind”, 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
> (like, by rpm --install) rather than by the daemon itself.

At least for /var/run I think it's common for systems to mount it
as tmpfs, so the directories might not be there on boot. But those can
always be created by the init script (or equivalent), it might be a
problem if run from inetd though.

> >>Would /var/run (or a subdirectory of it) be a better choice than /tmp ?
> >
> >/var/run might not be preserved across reboots, but regardless of that 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.
> After a system restart, all of the RPC services will restart and
> register themselves again.  If just rpcbind restarts, all that
> registration state is lost, so that's the point of saving it in a
> file.

Ah, yeah that makes more sense! More so given the configure option, I
should have written "AFAIS" or something like that. :)

> I don't have a preference wrt /var/run or /var/cache.

So given that this is actually run time state, /var/run seems more
appropriate, indeed.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 03 Jun 2010 21:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chuck Lever <chuck.lever@oracle.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 03 Jun 2010 21:15:02 GMT) Full text and rfc822 format available.

Message #35 received at 583435@bugs.debian.org (full text, mbox):

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 17:11:10 -0400
On 06/ 3/10 05:07 PM, Guillem Jover wrote:
> On Thu, 2010-06-03 at 16:34:01 -0400, Chuck Lever wrote:
>> On 06/ 3/10 04:27 PM, Guillem Jover wrote:
>>> 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
>>> “--with-statedir=/var/cache/rpcbind”, 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
>> (like, by rpm --install) rather than by the daemon itself.
>
> At least for /var/run I think it's common for systems to mount it
> as tmpfs, so the directories might not be there on boot. But those can
> always be created by the init script (or equivalent), it might be a
> problem if run from inetd though.

Sure, that makes sense.  Having the daemon create the directory also 
means there are fewer ways distributors can get this wrong.

>>>> Would /var/run (or a subdirectory of it) be a better choice than /tmp ?
>>>
>>> /var/run might not be preserved across reboots, but regardless of that 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.
>> After a system restart, all of the RPC services will restart and
>> register themselves again.  If just rpcbind restarts, all that
>> registration state is lost, so that's the point of saving it in a
>> file.
>
> Ah, yeah that makes more sense! More so given the configure option, I
> should have written "AFAIS" or something like that. :)
>
>> I don't have a preference wrt /var/run or /var/cache.
>
> So given that this is actually run time state, /var/run seems more
> appropriate, indeed.




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Thu, 03 Jun 2010 21:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chuck Lever <chuck.lever@oracle.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Thu, 03 Jun 2010 21:30:03 GMT) Full text and rfc822 format available.

Message #40 received at 583435@bugs.debian.org (full text, mbox):

From: Chuck Lever <chuck.lever@oracle.com>
To: linux-nfs@vger.kernel.org, Guillem Jover <guillem@debian.org>, 583435@bugs.debian.org
Subject: Re: Bug#583435: rpcbind: Insecure handling of state files
Date: Thu, 03 Jun 2010 16:07:50 -0400
On 06/ 2/10 07:25 AM, Aníbal Monsalve Salazar wrote:
> On Tue, Jun 01, 2010 at 02:09:07PM +0200, Guillem Jover wrote:
>> Hi!
>>
>> 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 daemon
>>> 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 performed at
>> the time of filing this report, but didn't seem to have any obvious
>> consequence, shows this which I noticed later on:
>>
>> ,---
>> gaara:~# /etc/init.d/rpcbind start
>> Starting rpcbind daemon....
>> gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
>> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>> root     23424  0.0  0.0  18768   704 ?        Ss   13:53   0:00 /sbin/rpcbind -w
>> gaara:~# /etc/init.d/rpcbind stop
>> Stopping rpcbind daemon....
>> gaara:~# dd if=/dev/urandom of=/tmp/rpcbind.xdr bs=1024 count=1
>> 1+0 records in
>> 1+0 records out
>> 1024 bytes (1,0 kB) copied, 0,000861307 s, 1,2 MB/s
>> gaara:~# /etc/init.d/rpcbind start
>> Starting rpcbind daemon....
>> gaara:~# ps axuOp|egrep '(^USER|[r]pcbind)'
>> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>> root     23440  0.0  0.0 4008972  772 ?        Ss   13:54   0:00 /sbin/rpcbind -w
>> `---
>>
>> The first start is a normal clean invokation, the second one is using
>> the crafted file. See how it has allocated almost 4 GiB. Disregard though,
>> me running all this as root, a user would be able to craft those files as
>> long as they were not already in /tmp.
>>
>> thanks,
>> guillem
>
> I'm sending this bug report to the linux-nfs mailing list.
>
> The original bug report is at http://bugs.debian.org/583435

Would /var/run (or a subdirectory of it) be a better choice than /tmp ?




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Mon, 07 Jun 2010 03:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josh Bressers <bressers@redhat.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Mon, 07 Jun 2010 03:00:03 GMT) Full text and rfc822 format available.

Message #45 received at 583435@bugs.debian.org (full text, mbox):

From: Josh Bressers <bressers@redhat.com>
To: oss-security@lists.openwall.com
Cc: Guillem Jover <guillem@debian.org>, Aníbal Monsalve Salazar <anibal@debian.org>, "Steven M. Christey" <coley@linus.mitre.org>
Subject: Re: [oss-security] CVE Request -- rpcbind -- Insecure (predictable) temporary file use
Date: Fri, 4 Jun 2010 15:39:57 -0400 (EDT)
Please use CVE-2010-2061 for this.

Thanks.

-- 
    JB


----- "Jan Lieskovsky" <jlieskov@redhat.com> wrote:

> Hi Steve, vendors,
> 
>    Guillem Jover pointed out:
>    [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#5
> 
> a deficiency in the way rpcbind gathered / saved registrations from /
> to
> dumped file(s). A local attacker could use this flaw to conduct
> symbolic
> link attacks, leading to un-authorized disclosure of sensitive
> information
> and / or to important system files data integrity corruption.
> 
> References:
>    [2] https://bugzilla.redhat.com/show_bug.cgi?id=599697
>    [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#15
> 
> Could you allocate CVE id for this?
> 
> Thanks && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Mon, 07 Jun 2010 03:00:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to oss-security <oss-security@lists.openwall.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Mon, 07 Jun 2010 03:00:05 GMT) Full text and rfc822 format available.

Message #50 received at 583435@bugs.debian.org (full text, mbox):

From: Jan Lieskovsky <jlieskov@redhat.com>
To: "Steven M. Christey" <coley@linus.mitre.org>, oss-security <oss-security@lists.openwall.com>
Cc: Guillem Jover <guillem@debian.org>, Aníbal Monsalve Salazar <anibal@debian.org>
Subject: CVE Request -- rpcbind -- Insecure (predictable) temporary file use
Date: Thu, 03 Jun 2010 21:10:34 +0200
Hi Steve, vendors,

  Guillem Jover pointed out:
  [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#5

a deficiency in the way rpcbind gathered / saved registrations from / to
dumped file(s). A local attacker could use this flaw to conduct symbolic
link attacks, leading to un-authorized disclosure of sensitive information
and / or to important system files data integrity corruption.

References:
  [2] https://bugzilla.redhat.com/show_bug.cgi?id=599697
  [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#15

Could you allocate CVE id for this?

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team




Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Mon, 07 Jun 2010 03:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to oss-security <oss-security@lists.openwall.com>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Mon, 07 Jun 2010 03:03:03 GMT) Full text and rfc822 format available.

Changed Bug title to 'CVE-2010-2061 rpcbind: Insecure handling of state files' from 'rpcbind: Insecure handling of state files' Request was from Aníbal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Mon, 07 Jun 2010 03:09:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Anibal Monsalve Salazar <anibal@debian.org>:
Bug#583435; Package rpcbind. (Sat, 17 Jul 2010 20:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Fritsch <sf@sfritsch.de>:
Extra info received and forwarded to list. Copy sent to Anibal Monsalve Salazar <anibal@debian.org>. (Sat, 17 Jul 2010 20:27:06 GMT) Full text and rfc822 format available.

Message #62 received at 583435@bugs.debian.org (full text, mbox):

From: Stefan Fritsch <sf@sfritsch.de>
To: 583435@bugs.debian.org
Subject: NMU diff
Date: Sat, 17 Jul 2010 22:24:40 +0200 (CEST)
[Message part 1 (text/plain, inline)]
Hi,

I have uploaded an NMU that changes the state file dir to 
/var/run/rpcbind. Diff is attached.

Cheers,
Stefan
[rpcbind_0.2.0-4.1.debdiff (text/plain, attachment)]

Reply sent to Stefan Fritsch <sf@debian.org>:
You have taken responsibility. (Sat, 17 Jul 2010 20:51:18 GMT) Full text and rfc822 format available.

Notification sent to Guillem Jover <guillem@debian.org>:
Bug acknowledged by developer. (Sat, 17 Jul 2010 20:51:18 GMT) Full text and rfc822 format available.

Message #67 received at 583435-close@bugs.debian.org (full text, mbox):

From: Stefan Fritsch <sf@debian.org>
To: 583435-close@bugs.debian.org
Subject: Bug#583435: fixed in rpcbind 0.2.0-4.1
Date: Sat, 17 Jul 2010 20:48:05 +0000
Source: rpcbind
Source-Version: 0.2.0-4.1

We believe that the bug you reported is fixed in the latest version of
rpcbind, which is due to be installed in the Debian FTP archive:

rpcbind_0.2.0-4.1.debian.tar.bz2
  to main/r/rpcbind/rpcbind_0.2.0-4.1.debian.tar.bz2
rpcbind_0.2.0-4.1.dsc
  to main/r/rpcbind/rpcbind_0.2.0-4.1.dsc
rpcbind_0.2.0-4.1_i386.deb
  to main/r/rpcbind/rpcbind_0.2.0-4.1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 583435@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stefan Fritsch <sf@debian.org> (supplier of updated rpcbind package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 17 Jul 2010 21:47:56 +0200
Source: rpcbind
Binary: rpcbind
Architecture: source i386
Version: 0.2.0-4.1
Distribution: unstable
Urgency: high
Maintainer: Anibal Monsalve Salazar <anibal@debian.org>
Changed-By: Stefan Fritsch <sf@debian.org>
Description: 
 rpcbind    - converts RPC program numbers into universal addresses
Closes: 583435
Changes: 
 rpcbind (0.2.0-4.1) unstable; urgency=high
 .
   * Non-maintainer upload by the security team.
   * CVE-2010-2061: Store state files in /var/run/rpcbind instead of /tmp.
     Closes: #583435
Checksums-Sha1: 
 3632c80e3ff10921fb83136650f6720afcc7ad37 1077 rpcbind_0.2.0-4.1.dsc
 10f1e09f3e18275d2e2b2b08ef65b23ecbce7cc5 8612 rpcbind_0.2.0-4.1.debian.tar.bz2
 34d263b3ba92fa1ab8f16733a6784c14fff92965 41204 rpcbind_0.2.0-4.1_i386.deb
Checksums-Sha256: 
 4d28bd0e9dbbf8ff76f2bd2902cfd2824f1578e988c4187cd284bc37f239de0f 1077 rpcbind_0.2.0-4.1.dsc
 a95b1c375420a559c3feaf422b43e80b6d435dd12460e8063ae27ac1ed04fb21 8612 rpcbind_0.2.0-4.1.debian.tar.bz2
 a3d0c41a951ce52bb31324e249105e3e4ae42cdec1f84b5ca401f8ae029bfc98 41204 rpcbind_0.2.0-4.1_i386.deb
Files: 
 1ae5c21e40cbcc92237df34f66b1776c 1077 net standard rpcbind_0.2.0-4.1.dsc
 dc83366af01c63fcfe6495a50a16f13f 8612 net standard rpcbind_0.2.0-4.1.debian.tar.bz2
 8a543851a81fcb6c913e4e6587aa468a 41204 net standard rpcbind_0.2.0-4.1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFMQhDhbxelr8HyTqQRAh/xAJ4g8SDQ++z2olVYzAT8mzWaHsueXwCfaidv
V3khWtQ/z1mOOXBnOiydmxI=
=q3Ew
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 18 Aug 2010 07:34:46 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 09:22:55 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.