VB 3.5 Plugin security

[OzRoy]

I'm looking at version 3.5 of VB and specifically the plugin system.

From what I can work out an admin can create a plugin and enter any arbitrary PHP code into the database and have it executed on the forums. And there is no way to disable this.

This is an extremely powerful and dangerous feature. Anyone with malicious intent can now do anything to the machine and can use it as a first step to gaining access to the box.

I would like to propose a change to this system so that PHP code is not executed from the database. All plugin code should be stored in physical files on the server in a specific plugin directory. The plugin table now just stores the name of the file. This filename should be sanitised and stripped of all '..' and '/' characters. Then instead of using eval() just include the file from the plugin directory.

This way system admins won't have to worry about an admin system that sends clear text passwords and malicious hackers gaining access through the forums. Trust can be kept to minimal number of protocols like sftp and ssh.

As Rasmus himself has said (and I agree) "If eval() is the answer, you're almost certainly asking the wrong question."

:)

[feldon23]

I'm looking at version 3.5 of VB and specifically the plugin system.

From what I can work out an admin can create a plugin and enter any arbitrary PHP code into the database and have it executed on the forums. And there is no way to disable this. An Administrator is generally someone who has full access to the web hosting account. They can delete any and all contents of the forum and website. If you do not want someone to have these privileges, you have no business granting them Administrator access.


This is an extremely powerful and dangerous feature. Anyone with malicious intent can now do anything to the machine and can use it as a first step to gaining access to the box.If someone has compromised an Administrator account and has a malicious intent, what is to prevent them from executing destructive MySQL queries?


I would like to propose a change to this system so that PHP code is not executed from the database. All plugin code should be stored in physical files on the server in a specific plugin directory. The plugin table now just stores the name of the file. This filename should be sanitised and stripped of all '..' and '/' characters. Then instead of using eval() just include the file from the plugin directory. Because of the object-oriented methods used by Plug-ins and vBulletin, a simple include() is impossible.

Also, requiring someone to upload Plug-ins via FTP defeats the whole purpose of Plug-ins to be installable via the interface. Permissions would have to be set to 0777 in most cases to allow what you want. Out of the box, vBulletin doesn't require a single directory to be CHMODded 0777.

I wonder if you have gone after Joomla? They allow entire ZIP files to be uploaded and the contents to be executed. Yet it has never been reported as a 'security flaw'.

This way system admins won't have to worry about an admin system that sends clear text passwords and malicious hackers gaining access through the forums.
What clear text passwords?

Again, if someone has compromised the Administrator account on a forum, you've already lost the war.

If your permissions on your web host are so screwed up that you fear an Administrator bringing down the machine through php code execution (he SHOULD only have as much access as nobody), delete /admincp/plugin.php.

[OzRoy]

An Administrator is someone who has full access to the FTP and web hosting account. They can delete any and all contents of the forum and website. If you do not want someone to have these privileges, you have no business granting them Administrator access.
No it's not. That's a system admin, not a forum admin. A forum admin should only have access to the forums. A system admin (as long as the server is set up securly) will only be access the system through secure encrypted channels like ssh and sftp. 99% of VB installs will not be installed on https servers.



If someone has compromised your Administrator account and has a malicious intent, them executing PHP code is the least of your worries.
Actually it is the greatest of my worries. A forum admin should be able to destroy nothing but the forum data. Deleting and editing threads etc etc. This is something that happened to us once many years ago. Luckily the person was only a disgruntled moderator and only managed to damage one forum. All that was required was a restoration of a database backup.

PHP code allows you to destroy a lot more than that. Recursive file deletions etc etc. That would require more than just a database restoration.



Because of the object-oriented methods used by Plug-ins and vBulletin, a simple include() is impossible.

Being OO will not make any difference. eval('$blah = "This is blah";'); is exactly the same as including a file that contains <?php $blah = "This is blah"; ?>

I use this technique in my code all the time, and my stuff is far more heavily OO than VB is.

[OzRoy]

Reply to the edit :)



Also, requiring someone to upload Plug-ins via FTP defeats the whole purpose of Plug-ins to be installable via the interface. Permissions would have to be set to 0777 in most cases to allow what you want. Out of the box, vBulletin doesn't require a single directory to be CHMODded 0777.

Exactly. You don't want people to make these sorts of changes via an insecure web interface. Why would permissions have to be 0777? Why can't they be 0644?



I wonder if you have gone after Joomla? They allow entire ZIP files to be uploaded and the contents to be executed. Yet it has never been reported as a 'security flaw'.

I have no idea what Joomla is.



What clear text passwords?

The clear text password that gets sent when you log in. Just because it's converted into an md5 hash does not make it any less a clear text password. I can log in with an md5 hash of your password just as easily as using the original.



If your permissions on your web host are so screwed up that you fear an Administrator bringing down the machine through php code execution (he SHOULD only have as much access as nobody), delete /admincp/plugin.php.
I know that. But the fact remains they can create a script that has access to everything the nobody user has access to. That includes other websites and system commands.

A breach of the vb admin is now a potential breach of all websites on the server. Who knows what they can do?

[feldon23]

I have no idea what Joomla is.
A content management system used by thousands of users. It used to be called Mambo.

Components, Modules, Templates, and other plug-ins are added by uploading a ZIP file through the Admin interface. These ZIP files contain PHP files, MySQL queries, etc. What you propose would make installing the simplest component into Joomla a nightmare as it automatically puts the files in the proper places for you when you upload the file.

[OzRoy]

A content management system used by thousands of users. It used to be called Mambo.

Components, Modules, Templates, and other plug-ins are added by uploading a ZIP file through the Admin interface. These ZIP files contain PHP files, MySQL queries, etc. What you propose would make installing the simplest component into Joomla a nightmare as it automatically puts the files in the proper places for you when you upload the file. No I'm not. Like I said I haven't looked at it. But why can't you just either unzip the file on the system manually, or unzip it on your machine and then FTP it up, or even better upload the zip file to an install directory.

Then once the files are uploaded log into the admin system. It detects there is a new module to install and prompts you. When you say install it then moves the files, and executes the SQL.

That will work. I know, because I write a system years ago that worked in a similar way.

This means a person will have to breach your website admin AND FTP access. No disrespect to the VB guys or anyone else, but I would rather not trust system level stuff like this to a PHP script even if it written by the smartest PHP coder in the world.

Code should never be uploaded via a web interface. All uploaded files should be sanitised for anything executable.

:)

[Wayne Luke]

Two things here...

1) You can turn off the plugin system completely and not allow any other forum administrator to edit the settings. Then only your account can change those settings.

Admin CP -> vBulletin Options -> vBulletin Options -> Plugin/Hook System.

If that isn't good enough you can add a single line of code to the config.php file to turn them off completely.

2) You can deny other administrators to the plugin system and other potentially malicious functions such as executing SQL queries and maintenance features via the Adminstrator Permissions already built-in.

http://www.vbulletin.com/docs/html/usergroup_admin_perms

[OzRoy]

Two things here...

1) You can turn off the plugin system completely and not allow any other forum administrator to edit the settings. Then only your account can change those settings.

Admin CP -> vBulletin Options -> vBulletin Options -> Plugin/Hook System.

If that isn't good enough you can add a single line of code to the config.php file to turn them off completely.

2) You can deny other administrators to the plugin system and other potentially malicious functions such as executing SQL queries and maintenance features via the Adminstrator Permissions already built-in.

http://www.vbulletin.com/docs/html/usergroup_admin_perms
OK That's good thank you. But I really want to use some sort of plugin system. The forums we run are heavily modified and the plugins would make our life much much easier.

What if I was to write the patch for you? I don't think it would take me that long. If you wish I could do it so it can switch between the two different methods based on a config file setting. Although I believe it would be better to switch completely and have the upgrade script convert the plugins automatically.

[merk]

I think you're overlooking the point that Wayne brought up - the administrator permissions system is designed to completely deny access to the plugin system unless you specifically enable it for an admin of your choice.

Whats the problem?

[merk]

As Rasmus himself has said (and I agree) "If eval() is the answer, you're almost certainly asking the wrong question."

All templates are evaled. How do you propose to keep the template system intact, while maintaining the ease of use without eval? Keep each template as a file?


The clear text password that gets sent when you log in. Just because it's converted into an md5 hash does not make it any less a clear text password. I can log in with an md5 hash of your password just as easily as using the original.

Theres over the top and theres over the top. If you're so worried about someone finding out your password maybe you should stop using http sites and only visit ones that support SSL. Or not use the internet at all. There are certain levels of anal and imo, if you've got a problem with the current md5 hashed password (which is not cleartext) then you should be using ssl.

Finally if you're so security aware you should already have configured open_basedir restrictions and be running PHP in safe mode.

[OzRoy]

Like I said previously, I don't care if the script is written by the best most infallible php coder in the world. It is not a good idea to allow any kind of arbitrary php code to be executed from a web interface. It adds another point of attack to the web server.

Passwords get lost. Passwords get stolen. Mistakes get made and permissions are accidently given to the wrong person. Any number of things can go wrong because like it or not humans make mistakes.

I like to think that I am security aware and I already am running using open_basedir, and I already am using safe_mode. Running every single website over https is just a bit extreme for a simple forum.

I really don't think this change is such a bad thing. It's fairly simple doesn't change the functionality that much, and will improve the security of the web server.

What I seem to get in response is accusations that I'm not doing everything in my power to run my websites as securly as I can. Well I am running things as securly as I can. I just want them to be as secure as possible. I really want to use the feature, I just do not believe this feature is as secure as it can be.

[Simetrical]

I think you're overlooking the point that Wayne brought up - the administrator permissions system is designed to completely deny access to the plugin system unless you specifically enable it for an admin of your choice.

Whats the problem?Password theft/guessing. Unlikely at the least, but technically possible even with the greatest security precautions, since vB doesn't currently allow certain users to be required to use HTTPS (man-in-the-middle attacks always work if you don't have encryption—for the purposes of logging in as you on the particular forum, the hashed password is cleartext). Even if only OzRoy's account has permission to install plugins, his/her password could still technically be stolen.

Granted, I don't think this eventuality is something 99.9% of admins will probably have to worry about, and it's probably not something that's worth Jelsoft's time. (Wouldn't man-in-the-middle attacks be impossible on the Internet anyway, unless you have direct access to an appropriate router and the ability to store and search a ridiculously large amount of data? If so, then make that "100% of security-conscious admins", since passwords on vB can't be brute-forced if you enable the appropriate option and no security-conscious admin should have a guessable password.)

[Wayne Luke]

What if I was to write the patch for you? I don't think it would take me that long. If you wish I could do it so it can switch between the two different methods based on a config file setting. Although I believe it would be better to switch completely and have the upgrade script convert the plugins automatically.

You can write anything you want and either release it or keep it to yourself. Personally, I feel it limits the plugin system and doesn't fit most of our customer's needs. I am not worried about mistakes because on my personal forums, I test everything and you need 2 different passwords to log into the AdminCP. No one has access to the plugin system except me and I can guarantee that.

[merk]

I still dont see the problem, a security concious admin like yourself shouldnt be using a guessable password, nor have it written down. The next obvious step would be to only ever access your site through SSL and make sure your pc is secure. Then the passwords being stolen argument is wiped out.

Your suggestion does add the ability to add plugins into a version control system if you use one, but I dont see it being useful (making it more of a pain in the ass, imo) at all for any other point.

[OzRoy]

What if there was a security flaw in mysql and someone was able to arbitrarily change records in your tables?

[Onimua]

Then it would be MySQL's problem, not really vBulletin. The developers of vBulletin would then need to find a way to patch it up.

[OzRoy]

Then it would be MySQL's problem, not really vBulletin. The developers of vBulletin would then need to find a way to patch it up.
Might that include disabling the plugin system or changing it so that the PHP code is not saved to the database?

[Wayne Luke]

You can easily take the plugin code and put it in 100 text files and then load those and use includes within the database. You would probably have to rewrite some plugins to handle object scope that the original author didn't take care of or didn't need to. Nothing in the plugin system needs to be changed to do that. However it isn't any safer. You can include files from other servers using include().

There are a lot of what-ifs in security that doesn't justify making the system impossible to use for a great majority of our customers. What-ifs rarely happen.

[merk]

What if there was a security flaw in mysql and someone was able to arbitrarily change records in your tables?

What if someone managed to get into the console of your pc? What happened if someone saw you typing your password over your shoulder? What if your linux kernel had significant vunurabilities that were exploited? What if you're infected with a rootkit?

What if.

[OzRoy]

What if someone managed to get into the console of your pc? What happened if someone saw you typing your password over your shoulder? What if your linux kernel had significant vunurabilities that were exploited? What if you're infected with a rootkit?

What if.
But those are all possibilities that existed pre 3.5. So you think it's OK to create new ones just because others already exist?

[beebi]

dose not be faster and more secure if they in file
like making folder named Plugin
and put the file in it

so I can use a zend technology with it

and add the file like adding user avatar

[beebi]

or adding export the plugin as a file

[merk]

But those are all possibilities that existed pre 3.5. So you think it's OK to create new ones just because others already exist?

Didnt realise mysql couldnt be compromised prior to 3.5.

[beebi]

and did u know if u have a big plugin
it's take a long time to open it

[OzRoy]

Didnt realise mysql couldnt be compromised prior to 3.5.
Of course that possibility existed. But they couldn't execute arbitrary code on your web server by accessing a database could they?

[merk]

Of course that possibility existed. But they couldn't execute arbitrary code on your web server by accessing a database could they?

Yes, every single version of vbulletin since at least 2.0.3 has had at least 1 phpinclude template.

[OzRoy]

It's obvious to me you really don't understand the potential danger this can cause. The Worst Case Scenario for VB is now unecessarily greater. As always any security concerns that get raised are immediatly shot down by the fan boys.

If you don't want to sit back and look at this objectively then there is nothing I can do. :)

[Brad.loo]

This isn't fanboyism, it's truth.

Placing the plug-in/product php code into the file system is no more secure than putting it in the database. The only differences between the two is that the first can be exploited by way of the file system and makes the plug-in system harder to use for the end user, the second is exploited via the database and is easier to use.

This problem is not specific to the 3.5 series, as stated before the phpinclude template allowed execution of php code and was in many versions before 3.5. The template system also resides in the database and could be used for an attack in the same way as the current plug-in system (although it is not as powerful nor as likely).

[merk]

It's obvious to me you really don't understand the potential danger this can cause. The Worst Case Scenario for VB is now unecessarily greater. As always any security concerns that get raised are immediatly shot down by the fan boys.

If you don't want to sit back and look at this objectively then there is nothing I can do. :)

What are you talking about? Anything the plugin system could have done could have been done in almost every prior version.

If you've got a problem with it, feel free to modify it. Just dont think that I share the same view as you (i dont like my head being under sand).

[OzRoy]

Well if that is the case I would think it should be a top priority to get the template system changed as well.

There is a reason why template engines like smarty impliment their own syntax and then "compile" it into physical files on the web server. It means they can control everything that can be done in a template. I was pretty sure VB did something similar with very basic controls like if statements etc. If it is just a straight eval then I'm amazed it hasn't been fixed.

At the very least VB should impliment it's own eval function that can strip the code of dangerous commands like system, exec, unlink and all file manipulation.

Basic common sense says that where eval is concerened, the supplied data must only come from a trusted source. Well I will tell you from experience that where humans are concerned there is no such thing as a trusted source, and you should always limit their abilities to the absolute minimum. VB is giving them abilities far beyong the absolute minimum.

[feldon23]

At the very least VB should impliment it's own eval function that can strip the code of dangerous commands like system, exec, unlink and all file manipulation.
If you familiarize yourself with vBulletin, you'll realize that only IF statements are possible in templates.

[Scott MacVicar]

We originally had a phpinclude template in 3.0.x and below that allowed you to execute PHP code, this was then dropped from 3.5.x in favour of the global_start hook which a plugin could use.

I've read through everything and I think forcing the files to be writeable by nobody is a bigger security concern for those on shared hosts than holding it within the database.

If you dont want plugins used then dont give them the permission, by default when adding admin permissions they are all set to no, so you'd have to explicitly give the admin permissions to edit the plugins. It's not something you could have accidently did. Same with SQL queries, you need to explicitly give permission for that.

It's a fine balance between usability and security, I'd honestly like to move plugins into the filesystem for the memory constraints but writing to the filesystem is another thing, i expect more than half our customers are on shared hosts, now you'd have to wonder how many are setup with security in mind.

[Paul M]

Wow, there are some paranoid people about.

What if you got run over by a bus tomorrow ....... :p

[OzRoy]

Wow, there are some paranoid people about.

What if you got run over by a bus tomorrow ....... :p
I don't think it's possible to be too paranoid about security. It's something that can potentially cost a company millions of dollars in damages if not handled correctly.

As for being run over by a bus I take as many precautions there as well, like looking both ways, and only crossing when safe :p