How to solve the arbitrary file deletion vulnerability in WordPress plugin WooCommerce

Technical Details

The permission processing mechanism of WordPress is mainly implemented by providing different functions for different roles. When the store administrator role is defined, it will assign the edit_users function to this role, so that They can directly manage the store's customer account. The entire permission assignment process occurs during the installation process of the plug-in. woocommerce/includes/class-wc-install.php:

//Shop manager role.add_role(       'shop_manager',      // Internal name of the new role       'Shop manager',      // The label for displaying       array(               // Capabilities                ⋮              'read_private_posts'     => true,              'edit_users'             => true,              'edit_posts'             => true,                ⋮       ));

The role permission information will be stored in the database as WordPress core settings, which means that the user role is now independent of the plugin, even if the plugin is not enabled , and will not affect related role permissions.

When an authenticated user attempts to modify other user information, the current_user_can() function is called, and then ensures that only privileged users can perform this operation. Current_user_can() function call example:

$target_user_id= $_GET['target_user_id'];if(current_user_can('edit_user',$target_user_id)) {    edit_user($target_user_id);}

The verification logic of the call is as follows: This user wants to use the ID $target_user_id to modify a specific user. Does he have the permission to execute?

Under the default configuration, the edit_users function allows users with permissions (such as store administrators) to edit other users, even administrator users, and then perform operations such as password updates. For security reasons, WooCommerce needs to specify whether store administrators can edit users, so the plug-in needs to add meta permissions. Meta functions can be called by current_user_can(). The value returned by the function under the default behavior is true, but the value returned by the meta permission function can determine whether the current user can perform such an operation. The following is the abstract function code of the WooCommerce meta permission filter:

function disallow_editing_of_admins( $capability, $target_user_id ) {       // If the user is an admin return false anddisallow the action    if($capability == "edit_user"&& user_is_admin($target_user_id)) {        return false;    } else {        return true;    }}add_filter('map_meta_cap', 'disallow_editing_of_admins');

For example, when current_user_can('edit_user', 1) is called, the filter will determine that the ID is 1 ($target_user_id) Whether the user is an administrator, and based on the results, determine whether to allow the user to operate.

Store administrator disables plug-ins

By default, only administrators can disable plug-ins. However, this vulnerability allows store administrators to delete any writable file on the server, so we can prevent WordPress from loading the plug-in by deleting WooCommerce’s main file-woocommerce.php.

This file deletion vulnerability exists in the logging function of WooCommerce. The logs will be stored in the wp-content directory in the form of .log files. When the store administrator wants to delete a log file, he needs to submit the file name as a GET parameter. The code snippet shown below is the vulnerable part:

woocommerce/includes/admin/class-wc-admin-status.php

class WC_Admin_Status{    public static function remove_log()    {    ⋮        $log_handler = newWC_Log_Handler_File();       $log_handler->remove(wp_unslash($_REQUEST['handle']));}

woocommerce/includes/log-handlers/class-wc -log-handler-file.php

class WC_Log_Handler_File extends WC_Log_Handler{    public function remove($handle)    {    ⋮        $file = trailingslashit(WC_LOG_DIR) .$handle;    ⋮unlink($file);

The problem here is that the file name ($handle) will be added to the log directory (wp-content/wc-logs/) and then passed to unlink( )function. When setting "$handle../../plugins/woocommerce-3.4.5/woocommerce.php", file wp-content/wc-logs/../../plugins/woocommerce-3.4.5/woocommerce. php will be removed, causing WooCommerce to be disabled.

The above is the detailed content of How to solve the arbitrary file deletion vulnerability in WordPress plugin WooCommerce. For more information, please follow other related articles on the PHP Chinese website!