Preg_Replace /e Modifier blocked by web host.

[tass23]

So my web host recently made some changes to their hosting security. One thing they did was block preg_replace using the /e modifier. This, of course, has broken my forums. I can't post new topics, at least half of the existing topics are not accessible. My web host says they have exhausted all available avenues to try and fix this issue without compromising security and have not found a solution.

Here is a sample error message:

Code Select Expand

Fatal error: SUHOSIN - Use of preg_replace() with /e modifier is forbidden by configuration in /home/abruner/public_html/forums/Sources/Subs.php(2513) : regexp code on line 2513

Warning: preg_replace() has been disabled for security reasons in /home/abruner/public_html/forums/Sources/Errors.php on line 114

A sample line of code for the above error from Subs.php:

Code Select Expand

$message = preg_replace($smileyPregSearch, 'isset($smileyPregReplacements[\'$1\']) ? $smileyPregReplacements[\'$1\'] : \'\'', $message);

I am using the latest SMF version 2.0.4. I've tried a brand new installation and just copying my existing boards table, same error. I've also tried a totally vanilla install using even the default theme and I get the exact same error trying to post a new topic. I even get the error when I'm trying to install a mod or even an update.
Does anyone have a solution for this besides switching web hosts?

[Kindred]

Slap your host upside the head with a herring... And then get a new host who is not full of crap.

[Chalky]

This seems to have affected several forums judging by the number of posts on this subject over the past week.  Who is your host?

[tass23]

This seems to have affected several forums judging by the number of posts on this subject over the past week.  Who is your host?

DirectNic is my host.
Is there a way around this issue? I've disabled evaluation of templates in the Admin area, but that doesn't help. I've been with my host for 10 years and I've been using SMF for almost 4 years now. I'd hate to have to switch either thing.

[Burke ♞ Knight]

It would appear that the host is treating paid accounts like they would free accounts.
Might be a good idea to at least shop around, and see what the prices/features of others is.

[MrPhil]

The first thing is to ask your host's tech support what's up with banning preg_replace()? It's vital for the function of many PHP applications, including SMF. The use of the "/e" modifier has been deprecated as a security risk, and will be removed in a future PHP, but that's no reason to ban the entire preg_replace() function. A better approach might be to examine each use of preg_replace /e and decide if it really is a security problem, rather than simply banning the whole function!

SMF does use the /e modifier in many places, and the next update (2.0.5) really ought to have this modifier removed. I fear it won't be removed until at least 2.1, possibly later.  If dimwitted hosts are going to simply ban the function, a quick fix might be to change the name to something in $smcFunc['replace'], and emulate preg_replace(), including the /e case. It's stupid to have to do that, but sometimes SMF has to adjust itself to stupid webhost practices.

Considering that SMF has still not added an arbitrary binary extension on to hashed attachment names, so that FileZilla doesn't screw it up, I'm not going to hold my breath. The developers are extremely resistant to changing SMF to account for the real world.

[tass23]

It would appear that the host is treating paid accounts like they would free accounts.
Might be a good idea to at least shop around, and see what the prices/features of others is.

For the price, it's tough to beat, plus I can pay month-to-month rather than get locked in to crappy service for a year or more.

The first thing is to ask your host's tech support what's up with banning preg_replace()? It's vital for the function of many PHP applications, including SMF. The use of the "/e" modifier has been deprecated as a security risk, and will be removed in a future PHP, but that's no reason to ban the entire preg_replace() function. A better approach might be to examine each use of preg_replace /e and decide if it really is a security problem, rather than simply banning the whole function!

SMF does use the /e modifier in many places, and the next update (2.0.5) really ought to have this modifier removed. I fear it won't be removed until at least 2.1, possibly later.  If dimwitted hosts are going to simply ban the function, a quick fix might be to change the name to something in $smcFunc['replace'], and emulate preg_replace(), including the /e case. It's stupid to have to do that, but sometimes SMF has to adjust itself to stupid webhost practices.

Considering that SMF has still not added an arbitrary binary extension on to hashed attachment names, so that FileZilla doesn't screw it up, I'm not going to hold my breath. The developers are extremely resistant to changing SMF to account for the real world.

This is the last I heard from the tech department at DirectNic:

"We did not entirely disable the preg_replace function, only in certain circumstances which can lead security holes. One of those circumstances is when used with eval, as is the case in your situation. SMF forums do have this set up with eval,l but they will work just as well with eval disabled (thereby allowing the preg_replace function to work on it's own and not be disabled).
You can disable eval using the instructions given at the SMF forums http://www.simplemachines.org/community/index.php?topic=290186.0 or if you are not comfortable doing that yourself we can do it for you (simply reply and ask us to disable eval for the forum and I'll take care of it). We do apologize for the inconvenience, but without this change the security of your site and the server it is hosted on is very vulnerable. We've been looking on this end for a solution, but the way the code is using the e modifier with the preg_replace function is dynamic and you would be better served contact SMF and seeing if they have a colution for it without using the /e modifier (which can be a security hole).

Jim M."

[MrPhil]

Apparently hosts are starting to block at least the /e flag on preg_replace(), if not the whole thing. /e is considered a security hole because, if used incorrectly, it could evaluate arbitrary (i.e., potentially dangerous) code. So, it sounds like SMF better get 1.1.19 and 2.0.5 out soon with the /e flag removed. If hosts are completely banning preg_replace() (out of laziness), it would have to be emulated with a new $smcFunc['preg_replace'].

[tass23]

Apparently hosts are starting to block at least the /e flag on preg_replace(), if not the whole thing. /e is considered a security hole because, if used incorrectly, it could evaluate arbitrary (i.e., potentially dangerous) code. So, it sounds like SMF better get 1.1.19 and 2.0.5 out soon with the /e flag removed. If hosts are completely banning preg_replace() (out of laziness), it would have to be emulated with a new $smcFunc['preg_replace'].

I hope this does get resolved soon...my forums support a custom online gaming server...
I'm guessing there's no "quick fix" for this...

[Storman™]

Apparently hosts are starting to block at least the /e flag on preg_replace(), if not the whole thing. /e is considered a security hole because, if used incorrectly, it could evaluate arbitrary (i.e., potentially dangerous) code. So, it sounds like SMF better get 1.1.19 and 2.0.5 out soon with the /e flag removed.

As from PHP 5.5.x  the preg_replace() /e modifier is deprecated so maybe the hosts have a valid point.

http://php.net/manual/en/migration55.deprecated.php

[MrPhil]

PHP is planning to remove it as it is considered a security exposure. However, for hosts to abruptly break every site that uses it is questionable. I would think it rare that unsanitized arbitrary user-input code would be fed to the function. Wouldn't it be better to warn all customers with preg_replace() /e to get updated pronto? SMF needs to do its part by releasing 1.1.19 and 2.0.5 as soon as possible. If hosts are only hitting /e usage, it would be sufficient to remove that flag from SMF and substitute something else (eval?). If they are completely disabling preg_replace(), it would be necessary to emulate the function everywhere it's used (I hope that's not the case).