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 perform
operations on URL.
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.
Because of security policy - i.e., if we choose to have security
policy that disallows running code with non-local origin influenced
by user data - we must do it full nine yards, not "we won't give it
to you by http, but you are welcome to do it by smb".
This is a valid point, but at the same time we need to consider the
consequences marking of smb:// as url will have on PHP applications
and weather this is something to be done in a patch level release.
Exploitation wise all of the hacks I've seen for remote code
execution were based on http as that provides the best degree of
anonymity for a hacker, a freehosting page somewhere sending php code
via text file. Use of SMB requires a more tricky infrastructure in a
form of an open smb share, usually meaning an exploited win32 box
that accepts incoming smb connections.
Now, if it would be not allowed by default by Windows (AFAIK it is
allowed) or there's known way to restrict that from Windows (which
I don't know of) - then we may defer this task to the OS, but if
there's none, then I don't see how http here would differ from
smb... If we say including file from http source is not OK, then
why would including file from smb source ok?
A firewall rule can be used to block outgoing smb connections quite
easily on both linux and windows.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
