Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Tue, 24 Feb 2009 09:48:17 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: svn commit: r746589 - in /apr/apr/trunk: ./ include/
	include/arch/unix/ include/arch/win32/ misc/unix/ misc/win32/
	threadproc/beos/ threadproc/netware/ threadproc/os2/
	threadproc/unix/ threadproc/win32/
Message-ID: <20090224094817.GA6199@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <20090221205948.E9CC52388882@eris.apache.org>
 <20090223113756.GA8593@redhat.com> <49A29396.7030107@apache.org>
 <20090223130323.GA23666@redhat.com> <49A2BB36.4000902@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <49A2BB36.4000902@apache.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Mon, Feb 23, 2009 at 04:05:26PM +0100, Mladen Turk wrote:
> Joe Orton wrote:
>>
>>> Also shm name is not predictable because the child pid is not
>>> known in advance (well one can make all 1...PID_MAX shm's, sure),
>>
>> tmp races are a security issue regardless of pid predicatibility (and 
>> in fact, pids are predictable on many platforms).
>>
>
> I made it unique. It can still fail in theory during the
> transition from two consequtive api calls
> (file_close and shm_create)

So the race is still there, and if an attacker wins that race, he can 
substitute a shm segment containing arbitrary data which the child 
process will pick up.  -1 stands on that basis.

Using an env var is also completely bizarre.  I can't imagine why on 
earth an application would want to work like this, rather than e.g. 
creating a shm segment in the parent and passing the name as a 
command-line option to the exec'ed child - or using a common config 
file.  Or using hard-coded paths.  But trying to shove this all into 
apr_proc_create() just seems like a disaster.

Regards, Joe