Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
that allow_url_include (and allow_url_fopen) can be easily worked around -
i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_include have any value than we
should fix it... What do you think?
I don't usually intervene in discussions nor rudenesses here, but this time
I felt I had to write this.. I'm pretty tired and reading such pathetic
posts is frustrating..
Well in first place I think Stefan should define in which side he is. He
pretends to be a PHP developer, but he doesn't act as one, as it posted a
message in his blog saying that a product that he supposedly helps to make
is insecure.. This is not really ethical, IMHO.
If he found some problem (security related or not), the first thing he would
have to do was to warn the PHP team (or fix it directly), not to release a
public advisory, nor an exploit, nor a slashdot/digg/... post, nor
whatever..
But yes, I agree with Ramus' patch.
Would requests to a smbserver, e.g.
\\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.
Well, this is a windows only problem. open_basedir will block it, but
probably it won't be blocked by anything else as it is handled as a local
file by the OS. However, we can/should also think in this problem.
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
