Serious vbseo security questions from a fellow programmer. An honest answer would be greatly appreciated.

I'm a php/mysql web developer. I would be considered to be an expert within my field. I've written software more complex with higher liabilities than vbseo.

Vbseo's programmers are obviously talented and knowledgeable within our field. I do not pretend to know more about vbseo than vbseo does, but I'm certainly qualified to ask a question and expect a non-evasive answer.

My vbulletin site is a hobby. I purchased vbseo with expectations of sound security, functionality comparable to what was described. Vbseo delivers perfectly on functionality, but these questions need to be answered, because the evasive answers everyone has been getting is not good enough, and this whole debacle is not being handled professionally. While my site was "hacked", this isn't a huge deal to me, but it did waste my time and the time of many others.

Situation: I'm running the latest version of vbulletin. I'm also running the latest version of vbseo. When my vbseo config is set as writable, a 3rd party (non-owner, non-group) can access and alter this file without access to my vbulletin admincp or vbseo admincp. The ability to write to this file also gives access to vbseo's vbulletin datastore. Changing this one single file to non-writable solves the security issue's practical application entirely.

Lets look at this problem for a minute. Even if the vulnerability point within the software is not vbseo's fault, why does writable access to a single xml file create so many security liabilities?

Lets assume for a minute that the security issue is with vbulletin itself, the fact that the writable nature of the config file is the make or break point for whether or not the vbulletin environment is compromised?

Even if these liabilities are unavoidable from the perspective of required functionality (obviously the script needs to have a high degree of control over vbulletin's controllers and views), why is this information being stored in a file that ever needs to be writable? Why is this information not stored entirely in the database?

The problem here is that vbseo is simply giving a blanket denial of any liability on their part, so let me reiterate: even if the "security problem" is not caused by vbseo, vbseo has created a massive, super attractive single point of attack for any vbulletin site runnings its software. Even if this issue is addressed by what ever entity caused the point of vulnerability, vbseo's very setup is created in a way that puts you at the mercy of the weakest link in your vbulletin setup.

Hello,

We appreciate your concerns on this matter. While I am not a developer of this product, I will try to address your concerns.

The writable config file exists solely as a middle-man. If offers a 'transport' layer from the CP to the datastore. All settings that run are called from the datastore, not from the config file.
Due to the nature of vbseo, and the inherit possibility of free-form entries, it is more than possible for someone to bring down their entire database/site with a bad string. While we do of course test and regex and try to limit input, there is only so much that we can do in a free-form entry. As a software developer your self, i'm sure you're aware of this issue.

Now, say a bad line gets entered, and ones site is now dead. vb admincp doesn't work, disabling hooks has 0 effect, and so forth. the ONLY fix is to get into phpmyadmin/similar, open the db, query the datastore table, parse and normalize the serialized data, find the bad data, perform the fix, re-serialze the data, run an update query.

The config file allows one (or our staff) to simply FTP up a new config.xml file (or a back up of last known good config) which will do all of that for a user and allow them to re-gain access to their site.

If you have ideas for a better solution that is code-able, we are all ears and will gladly take any suggestions to improve our product.

If's a similar reason why vbsecp.php exists at all, and isn't just another option under the vBOptions/settings menu. Should something go wrong, and the admincp ia inaccessible, the only way to fix it is with a raw query that is well over 99% of our customer base's heads.

To continue on from my post above, there is another reason why the config file is used: vbseo runs before vb does. There are many items and configuration tasks that run in vbseo long before the vb class for the database/etc classes are even initialized.