apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
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/
Date Tue, 24 Feb 2009 09:48:17 GMT
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


Mime
View raw message