When did curl_exec get disabled by default in ASL?

Only noticed today when I tried to update my WordPress blog, and it kept failing.

Turns out curl_exec was disabled. So I allowed it again via the ASL gui (Configuration > ASL Configuration) and it works fine again.

Odd.

Its new in 3.0:

https://www.atomicorp.com/wiki/index.ph ... ease_Notes

Oh righty, but as WordPress is a trust application, should it be blocked by default, seeing as not everyone may have noticed this change or issue yet, and WP is very very popular.

Trust WordPress? With all its millions of hacky plugins? Never.

Well to be fare Breun, unless you allow curl exec for WordPress, you can't update via the web interface, and also some plugins will not work at all.

Unfortunately, I host 3 WordPress sites on my server, so I have little choice, especially as I don't particularly want to do updates for each site via time consuming ftp. Especially as I don't get paid to do that.

Not every business is like your business. You can make the choice to take the risk and enable curl_exec, but that doesn't mean it should be the default for everyone, right? Especially not since we're talking about security software here.

Well as I understand it, if it is disabled in the ASL config (as in curl exec isn't allowed server wide) then it is disabled server wide, regardless of individual vhost php.ini settings.

Not that I know how to configure an individual php ini file.

That's correct.



If you're using mod_php, then there is no way to disable PHP functions per domain.

I'm just running a standard ASL install under CentOS 5.x and Plesk, so I would have to check and see if I'm using mod_php or not.

In Plesk you can choose between mod_php or FastCGI for PHP hosting. I believe Suhosin might allow one to disable PHP functions per domain, but I've never played with that.

Ok. I am starting to have an issue with curl_exec.

First of all WHMCS needs it in order to verify license. Wordpress as you said also. And I have 3 clients with custom modules which cannot run without curl_exec.

Now I would really need a reply from Scott or Mike on that.

Just how dangerous is curl_exec ??? And also is there any way to allow curl_exec on 2-3 domains specifically ?

This is a huge problem.

Don't forget that you can disable dangerous commands server-wide, then re-enable them individually if you use suhosin rather than PHP to disable the functions.

Disable them all in php.ini using suhosin, then disable all but the necessary ones in vhost.conf for the domain (again using the suhosin disable function).

It works for me, at any rate.

I disabled it via the ASL config in the web gui. I know it is risky, but I wish ASL allowed it for know apps like WordPress, or have a vhost by vhost enable/disable feature without having to use suhosin, which to be honest I have no idea what it is, should I use it, and what it will effect on the server, i.e. would using suhosin screw up something else up. After all I do run a lot of bespoke php services on my box, such as an sms service among others.

But I can understand why ASL disabled CURL_EXEC.

suhosin is probably one of the least intrusive security additions you can add to php. The defaults rarely cause any problems. About the only thing I've seen was when it flagged a script that was buried many, many directory levels deep and blocked it.

I don't use the defaults though -- I tighten things up a bit.

But most importantly, it lets you re-enable disable functions on a per-vhost level, which is ideal for me.

Faris.

Faris can you help out on that by sending us back what you did ?

So after you install suhosin with the defaults enabled you will be ok ?
And how do for example allow after enabling suhosin curl_exec on specific vhosts ?

If you could help out it would be owesome !