But, really, can somebody be both smart enough to get SMB to even
work, then manage to mount somebody else's untrusted drive or be dumb
enough to let somebody else mount their own SMB drive, and then
include() it i their PHP code? How likely is this scenario?
AFAIK, in order to use \\IP\share\f
On Sun, November 5, 2006 11:13 am, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
>> What's to say /drive/smb or letter:// is not an SMB device? Also why
>> break perfectly valid applications that perform operations on
>> networked
>> file systems?
>
> We are only talking about marking them as is_
Well, it looks like the overall consensus is that we add this
restriction, so let's add in it. It seems I am the only one somewhat
against it...
On 5-Nov-06, at 10:19 PM, Stanislav Malyshev wrote:
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is
On Mon, November 6, 2006 09:55, Richard Quadling wrote:
> I develop solely on and for our Windows network. I regularly use
> includes on 2 different servers via \\ rather than a mapped drive.
>
> I can see that adding \\ to the list of restrictions would be an issue
> for me.
>
> But also, it is a
I develop solely on and for our Windows network. I regularly use
includes on 2 different servers via \\ rather than a mapped drive.
I can see that adding \\ to the list of restrictions would be an issue for me.
But also, it is a trivial ini update to remove the problem. And it
DOES make PHP more
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is quite unusual. From my experience, I do not
believe the same could be said about smb.
How many apps really need to import includes from foreighn systems which
aren't mounted as drive letters? I don't th
On 5-Nov-06, at 1:22 PM, Stanislav Malyshev wrote:
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also
why break perfectly valid applications that perform operations on
networked file systems?
Well, it's the same as asking why break valid apps that per
Ilia Alshanetsky wrote:
>
> On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
>> The exact same argument could me made for a localhost
>> http or ftp include which we also disallow.
>
> For http allowing localhost access is dangerous simply because the
> person could make the script request itself
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on networked
file systems?
Well, it's the same as asking why break valid apps that perform
operations on URL. Because of security policy - i.
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
The exact same argument could me made for a localhost
http or ftp include which we also disallow.
For http allowing localhost access is dangerous simply because the
person could make the script request itself making a very nasty
request loop
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked
file systems?
We are only talking about marking them as is_url which doesn't
Ilia Alshanetsky wrote:
> What's to say /drive/smb or letter:// is not an SMB device? Also why
> break perfectly valid applications that perform operations on networked
> file systems?
We are only talking about marking them as is_url which doesn't have
anything to do with performing normal operati
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked file systems?
On 5-Nov-06, at 11:41 AM, Peter Brodersen wrote:
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alsha
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alshanetsky) wrote:
>> I think it's a fair assumption that a random host specified in that
>> way be treated as suspicious and lumped in under the
>> disable-includes-by-default category.
>
>What's random? Non localho
Hi,
At first I didn't think there would be an easy solution as it isn't
possible to distinguish between requests to a "local" SMB server and
an "outside" server. Both are network requests.
But on the other hand, requesting a file specific via network
protocols in PHP such as SMB or HTTP or FTP re
On 5-Nov-06, at 11:13 AM, Wez Furlong wrote:
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
What's random? Non localhost/127.0.0.1 ?
If someone discovers that it breaks their app
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implica
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.
On 4-Nov-06, at 4:12 PM, Peter
Hi Nuno,
>
> I was already expecting this kind of answer from you, but you clearly
> don't know me.
> The previous e-mail wasn't a personal attack nor an attack to your
> business, nor I was doing any type of propaganda against you.
Calling my actions unethical and my posts pathetic is kinda a pers
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.
Good point. Generally I'd say it belongs to the OS, but I'm not sure if
you can restrict this from OS side
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
I was already expecting this kind of answer from you, but you clearly don't
know me.
The previous e-mail wasn't a personal attack nor an attack to your business,
nor I
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
Before I posted about this, I brought this topic up MONTHS before PHP
5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6
tree.
And now please die or
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_inclu
On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>Yeah, we probably should. Had a chat with Wez about it too. Here is
>the patch. I think this catches the cases we are interested in:
>
> http://lerdorf.com/php/is_url.diff
>
>If someone could double
Stanislav Malyshev wrote:
> 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.
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_inclu
26 matches
Mail list logo
