apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: [Patch] redux; discussion of FD_CLOEXEC and APR_INHERIT
Date Tue, 18 Mar 2003 20:36:16 GMT
On Tue, Mar 18, 2003 at 12:37:16PM -0600, William Rowe wrote:
> At 04:03 AM 3/18/2003, Joe Orton wrote:
> >On Mon, Mar 17, 2003 at 11:59:42PM -0600, William Rowe wrote:
> >...
> >> If Brad or Brian are available - I will need your eyes on the Unix
> >> patches - and I don't want to go weeks before we release 0.9.2.
> >> If we can address these issues on those platforms by Wed that
> >> would be *really* terrific!
> >
> >So why not release 0.9.2 yesterday and add this in afterwards? This is a
> >pretty significant change in behaviour.
> Because the existing code is a security risk to some applications, and
> the security team has reinforced that the ASF shouldn't be dropping
> code that has known issues.  See Bjoern's earlier posts for additional, 
> very valid arguments.

What "security risk" is not setting CLOEXEC fixing for APR
applications? The argument I've seen that not setting CLOEXEC is a
"security risk" is that PHP will let you fork/exec any executable
which then inherits all the fds an httpd child has open.

1. if you care about that, turn on PHP safe mode, and don't let
script authors fork/exec anything at all.

2. otherwise: even when you set CLOEXEC, the arbitrary binary which
can be fork/exec from an untrusted PHP script can then just use
ptrace() to arrange for any httpd child to run arbitrary code anyway,
thereby gaining access to all the fds you went to so much effort to
avoid leaking.

I think this issue is getting over-hyped.


View raw message