wordpress delete any file vulnerability repair method

RIPS team disclosed wordpress 4.9.6 and any files that existed prior to version 4.9.6 removes the vulnerability by the vulnerability, the user has to log upload an attachment permission can delete any files on the site, the vulnerability is fixed in version 4.9.7, If you are using the following user 4.9.7 version of wordpress can update to the latest version to fix the flaw, do not want to update the webmaster can fix by the following method.

Theory and Hazard Vulnerability

Because WordPress files wp-includes/post.phpin the function wp_delete_attachement()is not safe handling when receiving deleted file parameters directly lead to the execution vulnerability.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function wp_delete_attachment( $post_id, $force_delete = false ) {
    ...
    $meta = wp_get_attachment_metadata( $post_id );
    ...
    if ( ! empty($meta['thumb']) ) {
        // Don't delete the thumb if another attachment uses it.
        if (! $wpdb->get_row( $wpdb->prepare( "SELECT meta_id FROM $wpdb->postmeta WHERE meta_key = '_wp_attachment_metadata' AND meta_value LIKE %s AND post_id <> %d", '%' . $wpdb->esc_like( $meta['thumb'] ) . '%', $post_id)) ) {
            $thumbfile = str_replace(basename($file), $meta['thumb'], $file);
            /** This filter is documented in wp-includes/functions.php */
            $thumbfile = apply_filters( 'wp_delete_file', $thumbfile );
            @ unlink( path_join($uploadpath['basedir'], $thumbfile) );
        }
    }
    ...
}

Code is seen in wp_delete_attachement()in unlink()the incoming $meta['thumb'], not subjected to any filtering process is called directly.

The purpose of this code is to delete the thumbnail image while deleting images. In the wp_delete_attachement()function, $meta['thumb']value checks from the database, and save it as an image representing the article in the custom field, but if the code is not $meta['thumb']of any content inspection and filtering, will lead to the use of this feature to execute arbitrary file deletion operations.

1
2
3
4
5
6
7
8
9
10
11
12
...
switch($action) {
...
    case 'editattachment':
        check_admin_referer('update-post_' . $post_id);
        ...
        // Update the thumbnail filename
        $newmeta = wp_get_attachment_metadata( $post_id, true );
        $newmeta['thumb'] = $_POST['thumb'];
 
        wp_update_attachment_metadata( $post_id, $newmeta );
...

/wp-admin/post.phpFragment behind, above, can see how the accessory attachment thumbnail belonging to the file name stored in the database. In the transfer value from the user and assign $_POST['thumb']a number to save to the database wp_update_attachment_metadata()function executes between, no safety measures to ensure that this is truly a thumbnail in the annex to edit.

And $_POST['thumb']can become any file path, this value can be saved to the relative path WordPress upload directory, when the attachment is deleted, the file will be deleted.

Repair method

Method One: wordpress upgrade to version 4.9.7 or above.

Method Two: put the following code into the currently used theme functions.php file:

1
2
3
4
5
6
7
8
add_filter( 'wp_update_attachment_metadata', 'rips_unlink_tempfix' );
function rips_unlink_tempfix( $data ) {
    if( isset($data['thumb']) ) {
        $data['thumb'] = basename($data['thumb']);
    }
 
    return $data;
}

Guess you like

Origin www.cnblogs.com/qqsvip/p/11853478.html