Debian Bug report logs - #605571
libapache2-mod-php5: Please enable pcntl functions

Toggle useless messages

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

From: Raphaël Hertzog <hertzog@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libapache2-mod-php5: Please enable pcntl functions

Date: Wed, 01 Dec 2010 12:14:02 +0100

Package: libapache2-mod-php5
Severity: wishlist

I have PHP code that wants to check the return value of pclose() and I
need the pcntl_wifexited() and pcntl_wexitstatus() functions to do
the work in a clean/portable way.

        $status = pclose($handle);
        if (!pcntl_wifexited($status) || pcntl_wexitstatus($status) != 0) {
		echo "FAIL";
	}

Unfortunately that function is only available in the -cli variant of PHP5
for a reason that I ignore.

You should either build this module in all variants or provide it as a plugin
like all other php-mysql/gd/foo packages.

Cheers,
-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

From: sean finney <seanius@debian.org>

To: Raphaël Hertzog <hertzog@debian.org>, 605571@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: libapache2-mod-php5: Please enable pcntl functions

Date: Wed, 8 Dec 2010 19:06:18 +0100

[Message part 1 (text/plain, inline)]

tags 605571 wontfix
thanks

hiya,

On Wed, Dec 01, 2010 at 12:14:02PM +0100, Raphaël Hertzog wrote:
> I have PHP code that wants to check the return value of pclose() and I
> need the pcntl_wifexited() and pcntl_wexitstatus() functions to do
> the work in a clean/portable way.
> 
>         $status = pclose($handle);
>         if (!pcntl_wifexited($status) || pcntl_wexitstatus($status) != 0) {
> 		echo "FAIL";
> 	}
> 
> Unfortunately that function is only available in the -cli variant of PHP5
> for a reason that I ignore.

well you may choose to ignore it, but we can't since we're the ones
who would be responsible for the fall-out :)

as a workaround you could probably call a wrapper script which could
communicate the status back to the caller in some slightly-less-clean
manner.

> You should either build this module in all variants or provide it as a plugin
> like all other php-mysql/gd/foo packages.

unfortunately i don't think it's compilable as a module (i.e. i don't
think there's an "=shared" option for this, it's either on or off).  if
i'm wrong then we could maybe do this as long as it defaults to off for
the apache flavored SAPI's and comes with a BIG FAT S3CURITY WRNING!!1!one!

in the meantime i'll tag it wontfix and we can leave it for further
discussion.


	sean

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 605571@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: sean finney <seanius@debian.org>

Cc: 605571@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: libapache2-mod-php5: Please enable pcntl functions

Date: Wed, 8 Dec 2010 20:28:31 +0100

Hi,

On Wed, 08 Dec 2010, sean finney wrote:
> > Unfortunately that function is only available in the -cli variant of PHP5
> > for a reason that I ignore.
> 
> well you may choose to ignore it, but we can't since we're the ones
> who would be responsible for the fall-out :)

I made no choice to ignore it, I just don't know the reason. Can it be
documented somewhere maybe?

> > You should either build this module in all variants or provide it as a plugin
> > like all other php-mysql/gd/foo packages.
> 
> unfortunately i don't think it's compilable as a module (i.e. i don't
> think there's an "=shared" option for this, it's either on or off).  if
> i'm wrong then we could maybe do this as long as it defaults to off for
> the apache flavored SAPI's and comes with a BIG FAT S3CURITY WRNING!!1!one!

So there are security concerns apparently... any specific security risk
or just the fear of letting malicious people use those functions to run
daemons where it was not intended?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #22 received at 605571@bugs.debian.org (full text, mbox, reply):

From: sean finney <seanius@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 605571@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: libapache2-mod-php5: Please enable pcntl functions

Date: Wed, 8 Dec 2010 21:37:25 +0100

[Message part 1 (text/plain, inline)]

hiya,

On Wed, Dec 08, 2010 at 08:28:31PM +0100, Raphael Hertzog wrote:
> So there are security concerns apparently... any specific security risk
> or just the fear of letting malicious people use those functions to run
> daemons where it was not intended?

i guess that'd be a bit problematic, but i'm sure an enteprising individual
could find a way to do the same thing via the standard system() calls.

the real problem as i see it is that having a working and direct path
to fork()/exec() opens up the possibility to read(/write?)[1] arbitrary
memory addresses in the apache processes, something that even an evil
developer trying to write malicious code should not be able to do.


	sean


[1] i have PoC code that can read "some interesting private things" from
    httpd's memory, but am not sure that anything useful can be done writing.

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 605571@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Debian Bug Tracking System <605571@bugs.debian.org>

Subject: Re: Please enable pcntl functions

Date: Thu, 26 May 2011 18:13:38 +0200

Package: libapache2-mod-php5
Severity: normal

Hi Raphael, Sean,

I am enabling the pcntl in CGI module (since it cannot apparently read
the apache2 memory) in the git.

But I was thinking if this poses any security problem for fastcgi or
FPM?  Maybe we could enable it for FPM, and at most it will be able to
read some FPM memory, which just could be prevented by creating more
FPM pools with user separation.

Any thoughts?

O.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libapache2-mod-php5 depends on:
pn  apache2-mpm-prefork | a <none>           (no description available)
pn  apache2.2-common        <none>           (no description available)
ii  libbz2-1.0              1.0.5-6          high-quality block-sorting file co
ii  libc6                   2.11.2-10        Embedded GNU C Library: Shared lib
ii  libcomerr2              1.41.12-2        common error description library
ii  libdb4.8                4.8.30-2         Berkeley v4.8 Database Libraries [
ii  libgssapi-krb5-2        1.8.3+dfsg-4     MIT Kerberos runtime libraries - k
ii  libk5crypto3            1.8.3+dfsg-4     MIT Kerberos runtime libraries - C
ii  libkrb5-3               1.8.3+dfsg-4     MIT Kerberos runtime libraries
ii  libmagic1               5.04-5           File type determination library us
ii  libonig2                5.9.1-1          Oniguruma regular expressions libr
ii  libpcre3                8.02-1.1         Perl 5 Compatible Regular Expressi
ii  libqdbm14               1.8.77-4         QDBM Database Libraries [runtime]
ii  libssl0.9.8             0.9.8o-4squeeze1 SSL shared libraries
ii  libxml2                 2.7.8.dfsg-2     GNOME XML library
ii  mime-support            3.48-1           MIME files 'mime.types' & 'mailcap
ii  php5-common             5.3.3-7+squeeze1 Common files for packages built fr
ii  tzdata                  2011d-0squeeze1  time zone and daylight-saving time
ii  ucf                     3.0025+nmu1      Update Configuration File: preserv
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages libapache2-mod-php5 recommends:
ii  php5-cli                5.3.3-7+squeeze1 command-line interpreter for the p

Versions of packages libapache2-mod-php5 suggests:
ii  php-pear                5.3.3-7+squeeze1 PEAR - PHP Extension and Applicati

Message #32 received at 605571@bugs.debian.org (full text, mbox, reply):

From: sean finney <seanius@debian.org>

To: Ondřej Surý <ondrej@debian.org>, 605571@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: Please enable pcntl functions

Date: Mon, 30 May 2011 08:12:06 +0200

On Thu, May 26, 2011 at 06:13:38PM +0200, Ondřej Surý wrote:
> Package: libapache2-mod-php5
> Severity: normal
> 
> Hi Raphael, Sean,
> 
> I am enabling the pcntl in CGI module (since it cannot apparently read
> the apache2 memory) in the git.

with libapache2-mod-php5, the php code is dlopen()'d and executed
in the memory space of the apache process itself, whereas the cgi script
is a seperately executed process.  there's still the possibility that
the cgi process could execute code that attached to another process
and did naughty things in a similar manner, but (a) i don't think it
needs pcntl enabled to do so, and (b) the linux kernel prevents
children of root-but-dropped-privs from attaching to their parents,
which would keep us safe (though only as a side effect).

but while the memory dumping issue might be moot, you still have the
quesiton of whether you want users to be able to spawn off long-lived
daemons that are immune to any other php engine controls (max lifetime,
memory, etc), and could probably have more usecases of the nefarious
variety rather than the legitimate.

The single feature request behind this from what was linked by Clint
was a user who wanted to do some "postprocessing".  Is it me or is
this just a case of the tail wagging the broken-design dog?  There are
already ways to accomplish that (system daemons, cron jobs, whatever)
which does not open this box of worms.

Perhaps Clint or someone else could put up a better justification for
why we want this in the general case, rather than to fix this one guys'
idea of "innovative" application design?

> But I was thinking if this poses any security problem for fastcgi or
> FPM?  Maybe we could enable it for FPM, and at most it will be able to
> read some FPM memory, which just could be prevented by creating more
> FPM pools with user separation.

As I understand it (correct me if I'm wrong), FPM processes don't start
off as root and drop privileges, meaning any fpm process could already
attach/backtrace any other fpm process in the same pool, with or without
the pcntl code.  So the memory dumping stuff isn't really an issue here,
at least not more than it already is.

That leaves us with the basically the same follow-up question as the
cgi stuff above, though: do we want to let php code fork/daemonize?


I'm not saying we should immediately back this out or anything; we have
a while before the next stable release to discuss this and I'm open to
the idea that maybe there is some reason we want to allow this.  And really,
i think you're doing all the heavy lifting with PHP these days Ondrej, so 
ultimately it's your opinion/decision that will probably matter most :)


	sean

Message #37 received at 605571@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <thomas@goirand.fr>

To: 605571@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: Bug#605571: Please enable pcntl functions

Date: Mon, 30 May 2011 16:54:25 +0800

On 05/30/2011 02:12 PM, sean finney wrote:
> That leaves us with the basically the same follow-up question as the
> cgi stuff above, though: do we want to let php code fork/daemonize?
> 
> I'm not saying we should immediately back this out or anything; we have
> a while before the next stable release to discuss this and I'm open to
> the idea that maybe there is some reason we want to allow this.  And really,
> i think you're doing all the heavy lifting with PHP these days Ondrej, so 
> ultimately it's your opinion/decision that will probably matter most :)
> 
> 
> 	sean

When it comes to my use case, I'm using SBOX to protect the executions
of PHP scripts (not the current version in SID, but a re-worked one,
which I will publish soon), and not PHP FPM. In my case, you can use
fork if you like, but at the end of the SBOX configured timeout, your
process (and it's child) will die anyway. So, in my case, having the
feature to fork is nice, rather than a security issue. I don't think
that signals, fork, and so on, are there *only* for daemons. Yes, it's
nice for them, but there are other use cases.

Also, if you believe that this is a security issue, what could be done
would be to activate the pcntl functions in the Git, then disable them
by default in php.ini, don't you think? This way, you still leave the
user a choice.

By the way, are these functions available for the php5-cli binary
already? I think they are strongly needed in there.

Your thoughts?

Thomas

Message #42 received at 605571@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Thomas Goirand <thomas@goirand.fr>, 605571@bugs.debian.org, sean finney <seanius@debian.org>

Subject: Re: [php-maint] Bug#605571: Bug#605571: Bug#605571: Please enable pcntl functions

Date: Mon, 30 May 2011 16:25:16 +0200

On Mon, May 30, 2011 at 10:54, Thomas Goirand <thomas@goirand.fr> wrote:
> On 05/30/2011 02:12 PM, sean finney wrote:
>> That leaves us with the basically the same follow-up question as the
>> cgi stuff above, though: do we want to let php code fork/daemonize?
>>
>> I'm not saying we should immediately back this out or anything; we have
>> a while before the next stable release to discuss this and I'm open to
>> the idea that maybe there is some reason we want to allow this.  And really,
>> i think you're doing all the heavy lifting with PHP these days Ondrej, so
>> ultimately it's your opinion/decision that will probably matter most :)
>>
>>
>>       sean
>
> When it comes to my use case, I'm using SBOX to protect the executions
> of PHP scripts (not the current version in SID, but a re-worked one,
> which I will publish soon), and not PHP FPM. In my case, you can use
> fork if you like, but at the end of the SBOX configured timeout, your
> process (and it's child) will die anyway. So, in my case, having the
> feature to fork is nice, rather than a security issue. I don't think
> that signals, fork, and so on, are there *only* for daemons. Yes, it's
> nice for them, but there are other use cases.
>
> Also, if you believe that this is a security issue, what could be done
> would be to activate the pcntl functions in the Git, then disable them
> by default in php.ini, don't you think? This way, you still leave the
> user a choice.
>
> By the way, are these functions available for the php5-cli binary
> already? I think they are strongly needed in there.
>
> Your thoughts?

I like the idea of enabling the pcntl, but disabling all functions
from the extension by default.  Implemented in 093d34f as static list,
and few minutes later updated it in 093d34f to pull the list of
functions from php_pcntl.h automatically.

O.
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/

Message #47 received at 605571-done@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Raphaël Hertzog <hertzog@debian.org>, 605571-done@bugs.debian.org

Subject: Re: [php-maint] Bug#605571: Bug#605571: Bug#605571: Please enable pcntl functions

Date: Thu, 23 Aug 2012 11:39:43 +0200

Version: php5/5.3.6-12

This was fixed a long time ago, just forgot to close this bug.

O.

On Mon, May 30, 2011 at 4:25 PM, Ondřej Surý <ondrej@debian.org> wrote:
> On Mon, May 30, 2011 at 10:54, Thomas Goirand <thomas@goirand.fr> wrote:
>> On 05/30/2011 02:12 PM, sean finney wrote:
>>> That leaves us with the basically the same follow-up question as the
>>> cgi stuff above, though: do we want to let php code fork/daemonize?
>>>
>>> I'm not saying we should immediately back this out or anything; we have
>>> a while before the next stable release to discuss this and I'm open to
>>> the idea that maybe there is some reason we want to allow this.  And really,
>>> i think you're doing all the heavy lifting with PHP these days Ondrej, so
>>> ultimately it's your opinion/decision that will probably matter most :)
>>>
>>>
>>>       sean
>>
>> When it comes to my use case, I'm using SBOX to protect the executions
>> of PHP scripts (not the current version in SID, but a re-worked one,
>> which I will publish soon), and not PHP FPM. In my case, you can use
>> fork if you like, but at the end of the SBOX configured timeout, your
>> process (and it's child) will die anyway. So, in my case, having the
>> feature to fork is nice, rather than a security issue. I don't think
>> that signals, fork, and so on, are there *only* for daemons. Yes, it's
>> nice for them, but there are other use cases.
>>
>> Also, if you believe that this is a security issue, what could be done
>> would be to activate the pcntl functions in the Git, then disable them
>> by default in php.ini, don't you think? This way, you still leave the
>> user a choice.
>>
>> By the way, are these functions available for the php5-cli binary
>> already? I think they are strongly needed in there.
>>
>> Your thoughts?
>
> I like the idea of enabling the pcntl, but disabling all functions
> from the extension by default.  Implemented in 093d34f as static list,
> and few minutes later updated it in 093d34f to pull the list of
> functions from php_pcntl.h automatically.
>
> O.
> --
> Ondřej Surý <ondrej@sury.org>
> http://blog.rfc1925.org/



-- 
Ondřej Surý <ondrej@sury.org>

Send a report that this bug log contains spam.