[RFC][DISCUSSION] script() and script_once()

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi all,

I would like to discuss my "must have it in PHP 7" item.

PHP RFC: script() and script_once()
https://wiki.php.net/rfc/script_and_script_once

Since script()/script_once() is almost copy of require()/require_once(), it
could be
INI option.

require_embed = On/Off

This allows existing PHP script to be secure without rewriting. If many of
you like
this, I'll change the RFC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by reeze — view source — reply

unread

The name seems ambiguous , how about "require_script/once" to match
"do_sth" pattern?

Hi all,

I would like to discuss my "must have it in PHP 7" item.

PHP RFC: script() and script_once()
https://wiki.php.net/rfc/script_and_script_once

Since script()/script_once() is almost copy of require()/require_once(), it
could be
INI option.

require_embed = On/Off

This allows existing PHP script to be secure without rewriting. If many of
you like
this, I'll change the RFC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Reeze,

The name seems ambiguous , how about "require_script/once" to match
"do_sth" pattern?

I thought so at first, too.
How about alternative way that turn 'require' into non embedded mode by INI
switch?

Since script()/script_once() is almost copy of require()/require_once(),
it could be
INI option.

require_embed = On/Off

Almost all users use 'require' only for script today, I guess.
I should have included this option in RFC. I'll do that now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Adam Harvey — view source — reply

unread

Since script()/script_once() is almost copy of require()/require_once(),
it could be
INI option.

require_embed = On/Off

Almost all users use 'require' only for script today, I guess.
I should have included this option in RFC. I'll do that now.

I'd be very, very -1 on any new INI setting that changes language
behaviour. We should be getting rid of those, not adding them.

I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in <?php and ?> tags? Are files included that way assumed to
be PHP and don't require <?php and ?> tags? Something else?

My initial reaction isn't positive, honestly — we already have four
statements that include files, and I'm not sure that another variation
is merited. There's only so much we can do to stop users shooting
their feet off: if "don't use untrusted input for file names with
include/require" isn't obvious, that's an education problem, not a
language one.

Adam

10 years ago by Leigh — view source — reply

unread

I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in <?php and ?> tags? Are files included that way assumed to
be PHP and don't require <?php and ?> tags? Something else?

This is my initial reaction to the RFC, it doesn't state the
specific difference between include/script. I understand what was
proposed in the nophptags RFC, but I have to make an assumption for
this RFC.

My assumption is that you want script* to not require <?php to begin
parsing. i.e. including /etc/passwd would be a parse failure.

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Leigh,

I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in <?php and ?> tags? Are files included that way assumed to
be PHP and don't require <?php and ?> tags? Something else?

This is my initial reaction to the RFC, it doesn't state the
specific difference between include/script. I understand what was
proposed in the nophptags RFC, but I have to make an assumption for
this RFC.

My assumption is that you want script* to not require <?php to begin
parsing. i.e. including /etc/passwd would be a parse failure.

I'm proposing SCRIPT only inclusion. This can be done by

allowing "<?php" only at to top of script
not allowing "?>" anywhere (We may allow at the end possibly)

Those who do not understand my point.
Please search by "PHP LFI" or "PHP file inclusion" for real life
security issues.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Leigh,

I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in <?php and ?> tags? Are files included that way assumed to
be PHP and don't require <?php and ?> tags? Something else?

This is my initial reaction to the RFC, it doesn't state the
specific difference between include/script. I understand what was
proposed in the nophptags RFC, but I have to make an assumption for
this RFC.

My assumption is that you want script* to not require <?php to begin
parsing. i.e. including /etc/passwd would be a parse failure.

I'm proposing SCRIPT only inclusion. This can be done by

allowing "<?php" only at to top of script

not allowing "?>" anywhere (We may allow at the end possibly)

Those who do not understand my point.
Please search by "PHP LFI" or "PHP file inclusion" for real life
security issues.

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre and all,

I'm proposing SCRIPT only inclusion. This can be done by

allowing "<?php" only at to top of script

not allowing "?>" anywhere (We may allow at the end possibly)

Those who do not understand my point.
Please search by "PHP LFI" or "PHP file inclusion" for real life
security issues.

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

This is "PHP inclusion" search result.

http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=PHP&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=

While I understand your opinion and the methodology is good practice
indeed, but I
cannot ignore the fact that PHP is MUCH more vulnerable than other
languages. Other
languages do not have many security issue like PHP. The reason is simple.

PHP enables embedding mode always for script inclusion.

Solution is simple also.

Provide non embedding mode script inclusion.

PHP is made for web and web is priority target of attackers.
PHP is better to be safer than now, the same level as other languages at
least.

I hope there will be a consensus to make PHP safer as other languages.

Your proposal requires admins to do the job. It's better to have developer
option.

Do any of you have other preferred option for developers?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Pierre and all,

I'm proposing SCRIPT only inclusion. This can be done by

allowing "<?php" only at to top of script

not allowing "?>" anywhere (We may allow at the end possibly)

Those who do not understand my point.
Please search by "PHP LFI" or "PHP file inclusion" for real life
security issues.

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

This is "PHP inclusion" search result.

http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=PHP&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=

While I understand your opinion and the methodology is good practice indeed,
but I
cannot ignore the fact that PHP is MUCH more vulnerable than other
languages. Other
languages do not have many security issue like PHP. The reason is simple.

PHP enables embedding mode always for script inclusion.

Solution is simple also.

Provide non embedding mode script inclusion.

PHP is made for web and web is priority target of attackers.
PHP is better to be safer than now, the same level as other languages at
least.

I hope there will be a consensus to make PHP safer as other languages.

PHP is just as safe than the other languages. PHP applicatons maybe
less, maybe more. I tend to see the amount of attacks as a proof of
success of a tool instead of a proof of the tool being unsafe (not
worth attacking 0.01% of the market when you can attack 75%).

Your proposal requires admins to do the job. It's better to have developer
option.

Do any of you have other preferred option for developers?

We do have one, it is called open_basedir, which I wanted to remove as
well but we agreed that it has its usefulness. One of them being
exactly to avoid the inclusion (and display) of critical information.
It indeed does not prevent one to include and display some text data
containing passwords or the likes when they are in the open_basedir
list but still.

And again, if one app allows unvalidated include/require (as in your
example), it will most likely do fopen and co as well and get data
displayed one way or another. Using yet another construct will again
give a false sense of security, solving a real problem using a bandaid
tape.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

PHP is just as safe than the other languages. PHP applicatons maybe
less, maybe more. I tend to see the amount of attacks as a proof of
success of a tool instead of a proof of the tool being unsafe (not
worth attacking 0.01% of the market when you can attack 75%).

Your proposal requires admins to do the job. It's better to have
developer
option.

Do any of you have other preferred option for developers?

We do have one, it is called open_basedir, which I wanted to remove as
well but we agreed that it has its usefulness. One of them being
exactly to avoid the inclusion (and display) of critical information.
It indeed does not prevent one to include and display some text data
containing passwords or the likes when they are in the open_basedir
list but still.

And again, if one app allows unvalidated include/require (as in your
example), it will most likely do fopen and co as well and get data
displayed one way or another. Using yet another construct will again
give a false sense of security, solving a real problem using a bandaid
tape.

I agree that user must be careful for any file function. This is not
limited to
include/require.

PHP is unique compare to other languages. PHP allows "script include
statements"
to open files as "script embedded file".

The result is completely different.

PHP file exposure and script execution
Others syntax error mostly

PHP == Fatal security issue, Others == Bug.

AFAIK, Ruby/Perl allows script execution with simple file validation. e.g.
Inject code after GIF file signature. However, Ruby/Perl apps were not
reported as vulnerable
to script inclusion because usual image check, e.g. check image size, can
prevent
attack image to be stored. Any other files are failed as syntax errors.

In contrast, PHP allows to embed script anywhere in a file. Image size
check does not
help at all. Converting size does not help also. (e.g. Attacker may embed
script in
color table. Changing size/recreating image cannot prevent attacks) If data
is written
into files, it can be used to execute. Session data file can be used to
attack, too.
These are the reason why file inclusion attacks against PHP applications
are so
popular/common.

Any PHP applications do file upload (image/etc) or data file writes
(wiki/session data) have
much higher script inclusion risk compare to others.

Other languages have fopen/readfile also. In this case, the result is the
same.
PHP is as safe as other languages in this area.

PHP has became as secure as other languages except script inclusion which
allows attackers take over servers. This is what I would like to change.

We have been removed embedded script from regex, i.e
preg_relace/mb_ereg_replace,
because it is dangerous. Why don't we remove embedded script from
include/require.
include/require is used to execute attack script more often than regex.
PHP7 seems
perfect opportunity to me.

Feasible options are

Introduce script only inclusion statement. script()/script_once()
Change require()/require_once() behavior not to embed script.

Let's have no more script/file inclusion attacks!

Regards,

P.S. Changing the result of bugs like this is defined as a security
measure by ISO 27000.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Pierre,

PHP is just as safe than the other languages. PHP applicatons maybe
less, maybe more. I tend to see the amount of attacks as a proof of
success of a tool instead of a proof of the tool being unsafe (not
worth attacking 0.01% of the market when you can attack 75%).

Your proposal requires admins to do the job. It's better to have
developer
option.

Do any of you have other preferred option for developers?

We do have one, it is called open_basedir, which I wanted to remove as
well but we agreed that it has its usefulness. One of them being
exactly to avoid the inclusion (and display) of critical information.
It indeed does not prevent one to include and display some text data
containing passwords or the likes when they are in the open_basedir
list but still.

And again, if one app allows unvalidated include/require (as in your
example), it will most likely do fopen and co as well and get data
displayed one way or another. Using yet another construct will again
give a false sense of security, solving a real problem using a bandaid
tape.

I agree that user must be careful for any file function. This is not limited
to
include/require.

PHP is unique compare to other languages. PHP allows "script include
statements"
to open files as "script embedded file".

The result is completely different.

PHP file exposure and script execution

Others syntax error mostly

PHP == Fatal security issue, Others == Bug.

AFAIK, Ruby/Perl allows script execution with simple file validation. e.g.
Inject code after GIF file signature. However, Ruby/Perl apps were not
reported as vulnerable
to script inclusion because usual image check, e.g. check image size, can
prevent
attack image to be stored. Any other files are failed as syntax errors.

In contrast, PHP allows to embed script anywhere in a file. Image size check
does not
help at all. Converting size does not help also. (e.g. Attacker may embed
script in
color table. Changing size/recreating image cannot prevent attacks) If data
is written
into files, it can be used to execute. Session data file can be used to
attack, too.
These are the reason why file inclusion attacks against PHP applications
are so
popular/common.

Any PHP applications do file upload (image/etc) or data file writes
(wiki/session data) have
much higher script inclusion risk compare to others.

Other languages have fopen/readfile also. In this case, the result is the
same.
PHP is as safe as other languages in this area.

PHP has became as secure as other languages except script inclusion which
allows attackers take over servers. This is what I would like to change.

We have been removed embedded script from regex, i.e
preg_relace/mb_ereg_replace,
because it is dangerous. Why don't we remove embedded script from
include/require.
include/require is used to execute attack script more often than regex. PHP7
seems
perfect opportunity to me.

Feasible options are

Introduce script only inclusion statement. script()/script_once()

Change require()/require_once() behavior not to embed script.

Let's have no more script/file inclusion attacks!

Regards,

P.S. Changing the result of bugs like this is defined as a security measure
by ISO 27000.

I do not put high value in this ISO ;-)

However, back to this exact feature. I am not convinced it is the
right way, there are many cases required more than just checking valid
code (<?php ...), like bash bang lines, phar or other script
archives-like solutions. And even with this solution, a compromised
server (via a web app or other) could still do whatever they want with
php scripts if the web server is not configured correctly. This is and
remains a OS level configuration problem.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

I do not put high value in this ISO ;-)

I am :) Almost all of my clients are ISMS or similar certified.

However, back to this exact feature. I am not convinced it is the

right way, there are many cases required more than just checking valid
code (<?php ...), like bash bang lines, phar or other script
archives-like solutions. And even with this solution, a compromised
server (via a web app or other) could still do whatever they want with
php scripts if the web server is not configured correctly.

With this proposal, <?php is allowed only at the top of a file.
For example, one of the easiest way to take over servers is embed
script into session data files. This is prevented effectively.

Users who allows phar/etc file uploads, they may have encryption or
compression as mitigation. This mitigation works well, but we cannot
enforce all users to adopt. It requires additional code/CPU resource...
It may ruin usability also. e.g. Files compressed by lzo or any other
fancy algorithms are not easily accessed.

I suggest users to configure their OS to protect all kinds of file
reading/writing
attacks. I agree 100%.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Pierre,

I do not put high value in this ISO ;-)

I am :) Almost all of my clients are ISMS or similar certified.

Marketing ;)

However, back to this exact feature. I am not convinced it is the
right way, there are many cases required more than just checking valid
code (<?php ...), like bash bang lines, phar or other script
archives-like solutions. And even with this solution, a compromised
server (via a web app or other) could still do whatever they want with
php scripts if the web server is not configured correctly.

With this proposal, <?php is allowed only at the top of a file.

So phar won't work with require_script? If that's the case then it does
look good to me.

For example, one of the easiest way to take over servers is embed
script into session data files. This is prevented effectively.

Users who allows phar/etc file uploads, they may have encryption or
compression as mitigation.

What does it have to do with upload?

Uploads are and should not be in a folder where php can be executed. This
is a basic configuration issue on almost all web servers.

This mitigation works well, but we cannot
enforce all users to adopt. It requires additional code/CPU resource...
It may ruin usability also. e.g. Files compressed by lzo or any other
fancy algorithms are not easily accessed.

I won't say it is good or bad but phar, to take one example, is widely used.

I suggest users to configure their OS to protect all kinds of file
reading/writing
attacks. I agree 100%.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

I am :) Almost all of my clients are ISMS or similar certified.

Marketing ;)

However, back to this exact feature. I am not convinced it is the
right way, there are many cases required more than just checking valid
code (<?php ...), like bash bang lines, phar or other script
archives-like solutions. And even with this solution, a compromised
server (via a web app or other) could still do whatever they want with
php scripts if the web server is not configured correctly.

With this proposal, <?php is allowed only at the top of a file.

So phar won't work with require_script? If that's the case then it does
look good to me.

Good point! I'll add this to the RFC.
I'm not too familiar to phar format.

Uncompressed phar has <?php at the top. I think .phar should be treated as
.php.
Compressed phar can be syntax error. I need to consider more including byte
compilers.

For example, one of the easiest way to take over servers is embed

script into session data files. This is prevented effectively.

Users who allows phar/etc file uploads, they may have encryption or
compression as mitigation.

What does it have to do with upload?

Uploads are and should not be in a folder where php can be executed. This
is a basic configuration issue on almost all web servers.

I agree that files are better/should be located other than web root.
Many apps only checks extension stores anything under web root.

Even if uploaded files are stored under non web root dir, attackers can use
path
traversal or even full path with bad code. As long as PHP can access,
attacker
can access to files for inclusion attacks. Compression/encryption prevents
attack files executing via script()/require(). Does this answer to you?

I realized that I didn't think of byte compiler format. I have to research
it.
IIRC, Zend allows to have custom script loader.
Could anyone give some pointers to look around? or give some ideas?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Pierre,

I am :) Almost all of my clients are ISMS or similar certified.

Marketing ;)

However, back to this exact feature. I am not convinced it is the
right way, there are many cases required more than just checking valid
code (<?php ...), like bash bang lines, phar or other script
archives-like solutions. And even with this solution, a compromised
server (via a web app or other) could still do whatever they want with
php scripts if the web server is not configured correctly.

With this proposal, <?php is allowed only at the top of a file.

So phar won't work with require_script? If that's the case then it does
look good to me.

Good point! I'll add this to the RFC.
I'm not too familiar to phar format.

Uncompressed phar has <?php at the top. I think .phar should be treated as
.php.
Compressed phar can be syntax error. I need to consider more including byte
compilers.

For example, one of the easiest way to take over servers is embed
script into session data files. This is prevented effectively.

Users who allows phar/etc file uploads, they may have encryption or
compression as mitigation.

What does it have to do with upload?

Uploads are and should not be in a folder where php can be executed. This
is a basic configuration issue on almost all web servers.

I agree that files are better/should be located other than web root.
Many apps only checks extension stores anything under web root.

Even if uploaded files are stored under non web root dir, attackers can use
path
traversal or even full path with bad code. As long as PHP can access,
attacker
can access to files for inclusion attacks. Compression/encryption prevents
attack files executing via script()/require(). Does this answer to you?

Not really. One will have to use exec and call php and the desired
file as a well configured server won't allow exec of php in the upload
or tmp dir, via the web server. It does not mean they are outside a
web doc root, only that no php (or other) will ever be executed from
there.

Also PHP is one part of the big picture, so I will simply summarize it
as "as long as one can access" instead of "as long as PHP can access".
That says all we need to know about emulating (badly anyway) OS
security features in PHP.

I realized that I didn't think of byte compiler format. I have to research
it.
IIRC, Zend allows to have custom script loader.
Could anyone give some pointers to look around? or give some ideas?

PHK and Phar f.e.

--
Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

Even if uploaded files are stored under non web root dir, attackers can
use
path
traversal or even full path with bad code. As long as PHP can access,
attacker
can access to files for inclusion attacks. Compression/encryption
prevents
attack files executing via script()/require(). Does this answer to you?

Not really. One will have to use exec and call php and the desired
file as a well configured server won't allow exec of php in the upload
or tmp dir, via the web server. It does not mean they are outside a
web doc root, only that no php (or other) will ever be executed from
there.

With SElinux, we can restrict access. However, PHP should be able to
read/write
uploaded files. PHP just read and execute them with include.

Is windows possible to prevent PHP to load script and execute? While
allowing write/read access?

I have similar idea for PHP to have data only dirs.

Also PHP is one part of the big picture, so I will simply summarize it
as "as long as one can access" instead of "as long as PHP can access".
That says all we need to know about emulating (badly anyway) OS
security features in PHP.

I realized that I didn't think of byte compiler format. I have to
research
it.
IIRC, Zend allows to have custom script loader.
Could anyone give some pointers to look around? or give some ideas?

PHK and Phar f.e.

Thank you. I'll check PHK.
I guess I should check Zend product, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Even if uploaded files are stored under non web root dir, attackers can
use
path
traversal or even full path with bad code. As long as PHP can access,
attacker
can access to files for inclusion attacks. Compression/encryption
prevents
attack files executing via script()/require(). Does this answer to you?

Not really. One will have to use exec and call php and the desired
file as a well configured server won't allow exec of php in the upload
or tmp dir, via the web server. It does not mean they are outside a
web doc root, only that no php (or other) will ever be executed from
there.

With SElinux, we can restrict access. However, PHP should be able to
read/write
uploaded files. PHP just read and execute them with include.

Again, I am talking about executing files. You can exclude a file,
path, folder for being invoked with a handler or similar things on a
web server. It has nothing to do with the PHP ability to access this
file as normal data. That won't prevent a file_get_contents+eval but
you get the idea.

Is windows possible to prevent PHP to load script and execute? While
allowing write/read access?

Yes and no. It is a web server role. Linux allows access restrictions
too, windows only provides a much more fine grained ACL. But again, it
is not what I am referring to.

I have similar idea for PHP to have data only dirs.

We have that already, not for php, but for web servers. This is their
job to deal with that.

Also PHP is one part of the big picture, so I will simply summarize it
as "as long as one can access" instead of "as long as PHP can access".
That says all we need to know about emulating (badly anyway) OS
security features in PHP.

I realized that I didn't think of byte compiler format. I have to
research
it.
IIRC, Zend allows to have custom script loader.
Could anyone give some pointers to look around? or give some ideas?

PHK and Phar f.e.

Thank you. I'll check PHK.
I guess I should check Zend product, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

With SElinux, we can restrict access. However, PHP should be able to
read/write
uploaded files. PHP just read and execute them with include.

Again, I am talking about executing files. You can exclude a file,
path, folder for being invoked with a handler or similar things on a
web server. It has nothing to do with the PHP ability to access this
file as normal data. That won't prevent a file_get_contents+eval but
you get the idea.

OK.

Is windows possible to prevent PHP to load script and execute? While
allowing write/read access?

Yes and no. It is a web server role. Linux allows access restrictions
too, windows only provides a much more fine grained ACL. But again, it
is not what I am referring to.

I have similar idea for PHP to have data only dirs.

We have that already, not for php, but for web servers. This is their
job to deal with that.

Yes, indeed.
engine=off
per dirs. This is what I suggest people. It cannot prevent other dir's
PHP scripts to load & execute. Public upload dir must have this setting.

My idea is controlling it from PHP, not as web server management.
It's better than per dir "engine=off".
It's not too important for me now, so it's not my priority.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi all,

I have similar idea for PHP to have data only dirs.

We have that already, not for php, but for web servers. This is their
job to deal with that.

Yes, indeed.
engine=off
per dirs. This is what I suggest people. It cannot prevent other dir's
PHP scripts to load & execute. Public upload dir must have this setting.

My idea is controlling it from PHP, not as web server management.
It's better than per dir "engine=off".
It's not too important for me now, so it's not my priority.

I take it back. I must include the idea in this RFC to be complete.
Since Zend allows custom script loader. Phar is integrated into PHP.
There are number of byte compilers. Some of them allow encryption.

We need script only include statement as well as data only dirs
or script only dirs. Specifying script only dirs is better because it is
white list. Programs should choose white list whenever it's possible
rather than black list.

If there is upload dir in system, PHP may execute files in the upload dir.
It's impossible to specify/detect which one is PHP script or not because
of custom script loader.

Therefore, PHP must have both script only inclusion and script only dirs
configuration.

Any comments on this?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Pierre Joye — view source — reply

unread

Hi Pierre,

With SElinux, we can restrict access. However, PHP should be able to
read/write
uploaded files. PHP just read and execute them with include.

Again, I am talking about executing files. You can exclude a file,
path, folder for being invoked with a handler or similar things on a
web server. It has nothing to do with the PHP ability to access this
file as normal data. That won't prevent a file_get_contents+eval but
you get the idea.

OK.

Is windows possible to prevent PHP to load script and execute? While
allowing write/read access?

Yes and no. It is a web server role. Linux allows access restrictions
too, windows only provides a much more fine grained ACL. But again, it
is not what I am referring to.

I have similar idea for PHP to have data only dirs.

We have that already, not for php, but for web servers. This is their
job to deal with that.

Yes, indeed.
engine=off
per dirs. This is what I suggest people. It cannot prevent other dir's
PHP scripts to load & execute. Public upload dir must have this setting.

My idea is controlling it from PHP, not as web server management.
It's better than per dir "engine=off".
It's not too important for me now, so it's not my priority.

But it is the key point. It is not PHP role to do it. PHP is not
alone. It is a server configuration job. But I have said that already
many times, we got our points :)

--
Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

But it is the key point. It is not PHP role to do it. PHP is not
alone. It is a server configuration job. But I have said that already
many times, we got our points :)

I understand your point.

We need both OS and PHP feature for perfection. Both of them are required.

Current PHP just reads & executes all accessible files by include.
I think you understand my point, too :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Lester Caine — view source — reply

unread

But it is the key point. It is not PHP role to do it. PHP is not

alone. It is a server configuration job. But I have said that already
many times, we got our points :)

I understand your point.

We need both OS and PHP feature for perfection. Both of them are required.

Current PHP just reads & executes all accessible files by include.
I think you understand my point, too :)

The question is essentially CAN one prevent PHP on it's own from running
things it shouldn't. In order to prevent people who do not understand
the security risks from 'making a mistake'. The answer is probably only
yes for a distribution that only comes from PHP. Other distributions are
not following guidelines now so expecting them to do in the future is
questionable? This is more about education of the whole infrastructure
but I don't see the point of yet another load mechanism? I thought we
had introduced all the necessary restrictions on include and require
already? From a 'nannying' point of view I would have thought it was
that hole which needed plugging since the people you are trying to
protect will not use a new mechanism anyway? I hope that I have my own
installations configured such that one can't upload material on-line
that can be accessed but having to ensure third party libraries are
using 'script' rather than 'include/require' seems a little problematic ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Lester and all,

But it is the key point. It is not PHP role to do it. PHP is not

alone. It is a server configuration job. But I have said that already
many times, we got our points :)

I understand your point.

We need both OS and PHP feature for perfection. Both of them are
required.

Current PHP just reads & executes all accessible files by include.
I think you understand my point, too :)

The question is essentially CAN one prevent PHP on it's own from running
things it shouldn't. In order to prevent people who do not understand
the security risks from 'making a mistake'. The answer is probably only
yes for a distribution that only comes from PHP. Other distributions are
not following guidelines now so expecting them to do in the future is
questionable? This is more about education of the whole infrastructure
but I don't see the point of yet another load mechanism? I thought we
had introduced all the necessary restrictions on include and require
already? From a 'nannying' point of view I would have thought it was
that hole which needed plugging since the people you are trying to
protect will not use a new mechanism anyway? I hope that I have my own
installations configured such that one can't upload material on-line
that can be accessed but having to ensure third party libraries are
using 'script' rather than 'include/require' seems a little problematic ...

Apparently, we don't provide key feature to eliminate script/file inclusion
attack that is unique to PHP.

I think the best way to go is to make 'require()' script only.

We need config to specify "script directory" to control script only
inclusion.
PHP must need to know if a file allowed to be executed. e.g.
require('../../file.php')
needs to know if it's safe to execute or not.

It must be fast. I'm thinking to cache all directory inode number specified
by "script directory" config at system initialization.

; All directories under these are script. Empty == disabled.
script_path="/var/www/lib;/var/www/html/"

; All directory under these ares files cannot be executed as script
; We don't need "engine=Off" for these directories any more.
upload_path="/var/www/html/upload;/var/www/html/user_images"

I'm not sure strtmp() or inode cache is faster. I'll take benchmark
to see if this is acceptable.

Please note that directory path configs are needed because of customizable
Zend script loader. i.e. PHP script or not cannot be decide by file
contents.

I'll rewrite whole RFC later.

Comments are appreciated.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Leigh — view source — reply

unread

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

I'm inclined to agree, this is just another mitigation against a
specific vector, not a solution. I'm sure given a little bit of time a
way to bypass it will be found.

Also introducing this in PHP 7 will not fix all of the currently
broken apps, nor will it get people to start using this method even if
they do upgrade to PHP 7.

I honestly think this is one of the cases where education is better .

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Leigh,

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

I'm inclined to agree, this is just another mitigation against a
specific vector, not a solution. I'm sure given a little bit of time a
way to bypass it will be found.

Also introducing this in PHP 7 will not fix all of the currently
broken apps, nor will it get people to start using this method even if
they do upgrade to PHP 7.

I honestly think this is one of the cases where education is better .

I think you probably didn't have chance to read my previous mail.
OS protection is not perfect and PHP is still too weak to inclusion
attacks...

We definitely need more protections.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.

I should have mentioned that OS level protection cannot be perfect neither.
For example, if app allow uploading image files, OS must allow access to
image files.

SInce PHP includes script with embedded mode, attacker can easily embed
attack script in image files....

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by francois@tekwire.net — view source — reply

unread

De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
How about alternative way that turn 'require' into non embedded mode by INI switch?

A big NO for me, as I am using 'include/require' in a lot of programs to include template files containing mixed text/php contents. And I'm probably not the only one.

Another reason is, like Adam, that I don't want another INI switch to change the interpreter behavior. When releasing a program, documenting and debugging ini switch dependencies is a nightmare. Even adding an 'extension=' line is a problem for many final users. So, please don't add another ini switch.

I am not opposed to the first option, while I don't really see the 'extremely severe security breach' brought by authorizing mixed text/php-code contents. Do you mean that including a forged path will release confidential file contents ? Well, that's right, but chroot exists, and I would prefer a way to ensure the forged path is detected as such and rejected by the include statement. Something like tainting (a good candidate for inclusion in PHP 7, even if it requires more work).

Cheers

François

10 years ago by Pierre Joye — view source — reply

unread

hi,

Hi all,

I would like to discuss my "must have it in PHP 7" item.

PHP RFC: script() and script_once()
https://wiki.php.net/rfc/script_and_script_once

I have proposed similar RFC before.
Optional PHP tags by php.ini and CLI options
https://wiki.php.net/rfc/nophptags

Compare to older proposal, it does not have issues like
possible script exposure by accident.

Please keep in mind that this discussion is not for
"Optional PHP tags by php.ini and CLI options".

Thank you all.

I do not see any appealing reason to add yet another set of include
function/ops, even less for ini settings.

My reasoning is simple. Nothing we can do will prevent one or the
other to shoot himself in each knees, many times.

While trying to protect them to do include $foo where $foo ==
"somereallybadpath", he will pretty much do the same with echo
file_get_contents($foo);

The history of php magic security issues tell me one thing, we should
leave that to the OS level and reports error the IO layers return,
when it fails.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Martin Keckeis — view source — reply

unread

I do not see any appealing reason to add yet another set of include
function/ops, even less for ini settings.

My reasoning is simple. Nothing we can do will prevent one or the
other to shoot himself in each knees, many times.

While trying to protect them to do include $foo where $foo ==
"somereallybadpath", he will pretty much do the same with echo
file_get_contents($foo);

The history of php magic security issues tell me one thing, we should
leave that to the OS level and reports error the IO layers return,
when it fails

True. The time where magic $_GET or similar file inclusions was a "common
pattern" (should be) gone.
Especially since psr0/psr4/composer/... came up

I think it would be more worth to include something like this:
https://wiki.php.net/rfc/escaper

10 years ago by Michael Wallner — view source — reply

unread

Hi all,

I would like to discuss my "must have it in PHP 7" item.

PHP RFC: script() and script_once()
https://wiki.php.net/rfc/script_and_script_once

Forget about the INI setting.
I think the perfect fit for that feature would be import{,_once}, but
that's definitely a no-go, because it would clash too hard with userland
as a reserved keyword.

--
Regards,
Mike

[RFC][DISCUSSION] script() and script_once()

Cheers,

Cheers,

Cheers,

-- Lester Caine - G8HFL

Cheers,

--
Lester Caine - G8HFL