WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#5564 closed enhancement (wontfix)

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

Reported by: keithdsouza Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: reporter-feedback
Focuses: 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 (10)

#1 @darkdragon
12 years ago

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).

#2 @darkdragon
12 years ago

What solution do you propose?

#3 @thee17
12 years ago

  • Keywords reporter-feedback added

#4 @DD32
12 years ago

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.

#5 @darkdragon
12 years ago

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.

#6 @darkdragon
12 years ago

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.

#7 @darkdragon
12 years ago

  • Priority changed from highest omg bbq to normal
  • Severity changed from critical to normal

#8 @darkdragon
12 years ago

  • Type changed from defect to enhancement

#9 @pishmishy
12 years ago

  • 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.

#10 @DD32
11 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm closing as wontfix, for a simple reason: Any further checks take up CPU time.

Infact, It could even be fixed since validate_file() is called on the file before including it.

Note: See TracTickets for help on using tickets.