config.xml settings changed randomly - security issue?

Originally Posted by Marco Mamdouh

Please check : Easy Security Tips for vBSEO customers

Originally Posted by Brian Cummiskey

Easy Security Tips for vBSEO customers

thanks... we just created an .htaccess file to protect the vbseo file. We also changed the vbseo control panel password again and chmod'd the config file to 644. 3 exploit attacks in 2 weeks. Hopefully this does the trick this time

So.... was the datastore code injected related to a vbseo exploit/bug?
Were we right?

Originally Posted by cinquecentisti

So.... was the datastore code injected related to a vbseo exploit/bug?
Were we right?

There is still no information if that was related to vBSEO or not. This issue was reported yesterday and fixed asap. However as mentioned on old thread , many boards that don't have vBSEO were effected of that issue.

The latest version still does not take servers that run suPHP into consideration as far as the part about how to properly permission the files.

It says to chmod 666 when it should be chmod 644.

Then when it is done is says to chmod 644 to write-protect the file when it should be set 444.

Originally Posted by GlowHost

The latest version still does not take servers that run suPHP into consideration as far as the part about how to properly permission the files.

It says to chmod 666 when it should be chmod 644.

Then when it is done is says to chmod 644 to write-protect the file when it should be set 444.

Can someone confirm this?

You can confirm it yourself actually.

Look at the upgrade instructions for the part that I talked about above. Those are the perms that vBSEO has written, and then I have mentioned what they should be for suPHP servers.

If you want to know if the file is writable or not and do not understand how to see that from the commandline, then the script itself will tell you. Load the main page of vBSEO and read if it tells you the file is writable or not. If it is writable at 644 then change it to 444 and then read the message...

Basically, the point is that you should make config file non-writable when setup is finished, applying whatever permissions are needed based on your server environment.

Originally Posted by Oleg Ignatiuk

Basically, the point is that you should make config file non-writable when setup is finished, applying whatever permissions are needed based on your server environment.

The problem that vBSEO is not acknowledging is that a lot, if not most of the forum installs these days will be running under suPHP. Most users do not have a great understanding of Linux permissions. So, they follow the instructions and assume everything is fine.

Perhaps I can offer a suggestion or two:
Update the docs for suPHP servers
Make vbseo.php aware of the server environment and tell the user exactly what permissions to use.

Read Only:
444 for PHP CGI (suPHP, PHPSuExec)
644 for PHP Module

When you suggest 755 for PHP files this is assuming PHP Module
If you detect PGP CGI then 755 should be set to 644 instead.

Here is some pseudo code that could get you started;

PHP Code:

$apache_modules = (function_exists('apache_get_modules') ? apache_get_modules() : ''); 
if(is_array($apache_modules)){ 
    foreach($apache_modules as $av){ 
        if(strtolower($av) == 'mod_suphp'){  // <--DETECT THIS!! Then set permissions appropriately
            $globals['755'] = 0644; 
            $globals['644'] = '0444';

        } 
    } 
} 


Edit: this may not work on all environments but PHP should be able to tell if this check fails and warn the user about it. apache_get_modules() probably will need to rely on exec() or shell_exec() or similar which is not always supported, but its easy enough to check and report that to the user.

Originally Posted by GlowHost

The problem that vBSEO is not acknowledging is that a lot, if not most of the forum installs these days will be running under suPHP. Most users do not have a great understanding of Linux permissions. So, they follow the instructions and assume everything is fine.

Perhaps I can offer a suggestion or two:
Update the docs for suPHP servers
Make vbseo.php aware of the server environment and tell the user exactly what permissions to use.

Read Only:
444 for PHP CGI (suPHP, PHPSuExec)
644 for PHP Module

When you suggest 755 for PHP files this is assuming PHP Module
If you detect PGP CGI then 755 should be set to 644 instead.

Here is some pseudo code that could get you started;

PHP Code:

$apache_modules = (function_exists('apache_get_modules') ? apache_get_modules() : ''); 
if(is_array($apache_modules)){ 
    foreach($apache_modules as $av){ 
        if(strtolower($av) == 'mod_suphp'){  // <--DETECT THIS!! Then set permissions appropriately
            $globals['755'] = 0644; 
            $globals['644'] = '0444';

        } 
    } 
} 


Edit: this may not work on all environments but PHP should be able to tell if this check fails and warn the user about it. apache_get_modules() probably will need to rely on exec() or shell_exec() or similar which is not always supported, but its easy enough to check and report that to the user.

I am sorry but i completely disagree with most forums running php with SuPhp. Usage of Suphp is less then 1% . Please note that we are dealing with thousands of customers and we know averages way better then you.

Hey, its not a pissing contest, but if you want it to be, I can tell you I deal with 20x that number (yes, tens of thousands of websites) on a daily basis and ALL of them run suPHP.

I know very few other web hosts that do not run suPHP.

I'd be curious as to how do you gather those statistics?

You don't (mental calculations don't work here) because you don't check in the scripts for one, and secondly your install team until recently was not even checking for suPHP or even aware it existed judging by the sound of this thread where everyone from vBSEO is telling the people in this thread that their servers are screwed up. What a laugh.

I have had to set the permissions correctly on many many boards including my own after you guys installed updates in the past. That tells me no one was checking or knew. So how do you have numbers one wonders?

Just today I saw 2 forums upgraded by your guys with the new vBSEO for one of our customers. I checked when you guys were done to make sure the permissions were done right this time. I was surprised to see that you took suPHP into account this time and set his permissions correctly...so that is a step in the right direction. At least you guys are paying attention now and know to look for it. Thanks for that.

Anyways, if you guys do not care about your thousands of customer's website security or don't feel like making docs that are compatible for everyone, completely up to you.

But instead of being defensive you would be better off gathering REAL statistics of the numbers of users that use suPHP and you might be surprised.

1% of 1000 is 10 so to me it sounds like you don't care about those 10 people that paid you $150 bucks a pop.

Every install or upgrade we do, we see the customers' phpinfo/etc. suPHP is rarely used.

We support information for the VAST MAJORITY of users.
If YOU are set up differently, then YOU should know what modifications you need to make to mimic said setting.


You will also find that 99% of our htaccess articles/etc deal with apache. If you are on nginx/etc, then you also need to convert to match your system.

Originally Posted by Brian Cummiskey

Every install or upgrade we do, we see the customers' phpinfo/etc. suPHP is rarely used.

We support information for the VAST MAJORITY of users.
If YOU are set up differently, then YOU should know what modifications you need to make to mimic said setting.

So how come on every install that you do the permissions are not set correctly?

suPHP is one of several versions that interface with PHP CGI so it might be phpsuexec, DSO or several other flavors. phpinfo doesn't reveal suPHP as you mentioned, sorry, but again nice try. Why do you guys all try to beat up your posters and dodge the bullet?

If you want an accurate count, look at:

Server API:

In php.info

If it says
"Server API: CGI"

Those are your users that require lower, more secure permissions.

Now you can update your counts and see what % really uses the CGI interface.

PS CAPS are pretty rude coming from a PROFESSIONAL ORGANIZATION.

You need a PR PERSON or someone that cares in general about customer feedback. Or at least someone who pretends to care about feedback.

PSS what does this mean?: "99% of our htaccess articles/etc deal with Apache. If you are on nginx/etc, then you also need to convert to match your system."

Ok, so if you "support" Engine X why not make docs specific to that server as well?

This will be the last post in this thread. This bantering does no good for anyone, especially when basically everything you are complaining about is being backed up with inaccurate information.

Further, It is completely off topic for the thread at hand.