Ticket #5564 (new enhancement)

Opened 11 months ago

Last modified 10 months ago

Non Plugin Files Cab Be Easily Included In Current Plugins using database Manipulation

Reported by: keithdsouza Assigned to: anonymous
Priority: normal Milestone: 2.9
Component: General Version:
Severity: normal Keywords: reporter-feedback
Cc:

Description

A non plugin file can be easily added to active plugins by using database manipulation by unserializing data and serializing data back to the database after adding in new rows to the array.

Once a plugin file has been included inside wp_options table under option_name active_plugins no additional checks are done other than validating if the file is existing and validated to not have any programatical and fatal errors.

Could be used to exploit users once user gains access to the database either via a corrupt theme or plugin as any one having access to the DB can manipulate the active_plugins column.

Change History

01/02/08 02:50:10 changed by darkdragon

Actually, I find this quite useful as a feature. It has allowed me to activate required plugin modules that I depend on and still allow the plugins to show up in the plugin list.

What you are suggesting could have some speed implications.

I also think that something as speed critical as the Plugin API could use some extra checks and balances, but would really do more harm for a lot of users.

There is really not much that can be done with corrupt themes and plugins except having an active community which informs about such things. It also would help to get plugins from "trusted" sources, which are reviewed (however, probably does not have "evil" checks).

01/02/08 02:53:30 changed by darkdragon

What solution do you propose?

01/02/08 04:05:41 changed by thee17

  • keywords set to reporter-feedback.

01/02/08 05:34:08 changed by DD32

If you have access to the database via any means, You can create an admin account and modify the active plugins via the UI.

If you have local access to the server, you can add files that can automatically be included by WP.

WordPress has to assume the data given to it is sane and expected, When entering data into the database/files WP can check that its authorized change, but if its coming from the filesystem or database, its impossible for WP to know if its supposed to be like that.

I'm going to suggest setting to invalid, pending 2nd oppinion.

01/02/08 06:16:45 changed by darkdragon

I agree, but I thought the ticket was more that WordPress should double check that the plugin file is valid (with comments) before including during the wp-settings plugin inclusion.

However, while WordPress should do this, it really wouldn't prevent anything. Like DD32 said, there are other ways to go about this. If a hacker is going to go through this method, then I think the hacker is just playing with the victim.

Again, the hacker would have already had to have access to the filesystem/database before initiating this run. Well, then again, it would be nice to have many layers, but nothing is preventing the hacker from adding valid plugin comment information.

I think it would be quite difficult to fix with very little gain from doing so. Not to mention that checking the plugin files on every page load could do well to slow down WordPress.

01/02/08 06:22:28 changed by darkdragon

Well, since I'm not a security expert, I'm not quite sure if this if valid or not. I keep thinking of a possible system, but you would almost have to have PHP extension support for this kind of thing.

Building Web Database Logic into a PHP extension is probably just asking for more work than it is worth it.

Any smarter person can explain how the ticket can be prevented? I would be willing to make a patch if it is within my ability to do so.

01/28/08 06:40:59 changed by darkdragon

  • priority changed from highest omg bbq to normal.
  • severity changed from critical to normal.

01/28/08 06:41:06 changed by darkdragon

  • type changed from defect to enhancement.

02/04/08 14:58:46 changed by pishmishy

  • component changed from Security to General.

I'm moving it from the Security component. There may be extra checks that could be done here but none will remove the security risk. A malicious theme could just manipulate the database directly I'm sure, and we accept that risk.