1
dejadingo
[critical] hosting service turning off allow_url_fopen
  • 2007/12/14 18:02

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


My hosting service has turned off allow_url_fopen for all shared host sites (which mine are). I've searched the XOOPS code base for usage of fopen() and although Protector prefers allow_url_fopen OFF, there seems to be a lot of fopen() usage throughout the system.

I'm currently using XOOPS 2.0.16, mostly with my own modules. Can anyone please comment on what in the base system I can now expect to stop functioning?

2
Will_H
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 18:59

  • Will_H

  • Friend of XOOPS

  • Posts: 1786

  • Since: 2004/10/10


nothing. You're golden

3
BlueStocking
Re: [critical] hosting service turning off allow_url_fopen

@dejadingo;

hypermart.net here...

I also recieved the notice, but I had requested that to be applied to my site sometime before the notice came out recently. This is a security precausion that should be implimented on your site and others on shared servers.

As the infamous Martha Stewart would say, "it's a good thing"

BlueStocking
Question:
"Can anyone please comment on what in the base system I can now expect to stop functioning?"

Answer:
Unauthorized access.
hhttps://xoops.org/modules/repository .. It is time to get involved - XOOPS.ORG

4
dejadingo
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 20:31

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


Yes, it's *obvious* this is a good thing in terms of hacker protection. However, there are certainly issues with PHP code that will not work, or works differently, with allow_url_fopen truned off. And I'm certainly not golden here.

Here's one thing I've found already, and I'm sure more will follow as I test every single piece of every single page, both user and admin functionality.

The PHP function getimagesize() will not accept a URL, even one that is within my own site. This affects (at least my version of) XoopsPartners 1.1.

Perhaps all the various calls to fopen() in the system are benign, but I will have to check them also.

5
BlueStocking
Re: [critical] hosting service turning off allow_url_fopen

My notification csme with the following when I followed the link for more information.
Quote:

Important Security Notice about PHP Scripts
If your site employs PHP scripts, please note that we have disabled the allow_url_fopen functionality in php.ini files at a platform level for security reasons. More information about the security issues associated with allow_url_fopen is available on the PHP Security Consortium Web site.

If you experience PHP issues as a result, you can enable allow_url_fopen for your php.ini file by using our php.ini editor.


Check with your server and ask them to restore the fopen to your site if you didn't recieve the doit yourself tool.

Under your set of circumstances, that would be my suggestion ...

BlueStocking
hhttps://xoops.org/modules/repository .. It is time to get involved - XOOPS.ORG

6
Will_H
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 21:39

  • Will_H

  • Friend of XOOPS

  • Posts: 1786

  • Since: 2004/10/10


Ok, the XOOPS CORE is golden.

I certainly hope you don't expect us to list off every single module that once utilized fopen.

It is a security risk, turning it back on would be anything but intelligent.

XoopsPartners??? isn't that from like 2005? try SmartPartner its current, and supported by the beautiful minds over at smartfactory.

Sure it may require a little work for you to secure (and update) your site, but... cmon thats part of the deal.

BOL man.

Quote:

PHP has several functions that take filenames as one of their arguments: fopen(), file() and some others. If allow_url_fopen is set to On in php.ini, those functions also accept URLs instead of regular files, and they connect to the server in question with the correct protocol. This functionality is vulnerable to some CRLF Injection attacks.

7
dejadingo
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 22:12

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


No, I don't intend to ask to have it turned back on, even if I could. And no, I don't expect a list of all the modules that once were vulnerable.

I'm glad the XOOPS CORE is not a problem, and I am therefore concentrating on the modules. The list of vulnerable php functions is helpful in that search. Any other such functions someone cares to enumerate would be welcome.

Thank you.

8
Will_H
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 22:31

  • Will_H

  • Friend of XOOPS

  • Posts: 1786

  • Since: 2004/10/10


hhttp://phpsec.org/projects/guide/ probably be helpful. None the less its a good read.

http://www.php.net

You can start with your php version and see what exploits were found since your version was current.

I imagine you are still using php4

9
Catzwolf
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/14 22:37

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Why don't you just replace each fopen instance with 'cURL' instead?

10
vaughan
Re: [critical] hosting service turning off allow_url_fopen
  • 2007/12/16 19:11

  • vaughan

  • Friend of XOOPS

  • Posts: 680

  • Since: 2005/11/26


it is my understanding that if fopen is disabled in php, XOOPS defaults to using the snoopy.php class instead? or would modification be needed for modules that require fopen to use snoopy.

but either way, it is best to use snoopy instead of enabling fopen.

Login

Who's Online

195 user(s) are online (76 user(s) are browsing Support Forums)


Members: 0


Guests: 195


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Oct 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits