Double page generation and random page author.

Hello,

I discovered a bug within Pro Sites on which the Pro Site page (/pro-site/) is generated multiple times in rare scenarios.

This will cause a /pro-site-2/ page to emerge.

Also, the /pro-site-2/ page has been assigned a random author from my network. One who has not been registered as a user on the main blog.

This caused a little confusion (might I be hacked??!? Nope :slight_smile: ) but it's just a bug :slight_smile:

Nevertheless, thanks for the great work guys! Keep it up :slight_smile:

  • Adam Czajczyk
    • Support Gorilla

    Hello Sybre,

    I hope you're well today and thanks for pointing this out!

    Would you please be so kind and elaborate a bit on this issue? It would be great if you could give ma short "case scenario" or steps that I could take to reproduce this on my site. It would help me investigate the issue.

    Looking forward for your answer!

    Cheers,
    Adam

  • Sybre Waaijer
    • The Incredible Code Injector

    Hi @Adam Czajczyk

    Thanks for dropping by.

    I'm not sure how to reproduce this, since I haven't touched Pro Sites settings regarding a gateway since mid 2014 (I use a manual gateway and signup form through Gravity Forms since then).

    I'm sure this issue is related to the function create_checkout_page() within pro-sites.php.

    Within the wp_insert_post array, no 'post_author' is given.
    I think the wp_insert_post uses the ID of whoever is running the PHP function at that point, I think it was the case of that random user who got assigned as post author.

    To prevent this, we pass the ID of the owner of that site. I think the parameter could be given with the following code block, type casting is optional:

    // Code here
    
    switch_to_blog( $checkout_site );
    
    // Code here
    
    //* Best I could do to find the blog owner at the moment.
    $admin_email = (string) get_bloginfo( 'admin_email' );
    $admin_user = (object) get_user_by( 'email', $admin_email );
    $admin_id = (int) $admin_user->ID;
    
    $id = wp_insert_post( array(
    				'post_title'     => $this->get_setting( 'rebrand', $default_title ),
    				'post_status'    => 'publish',
    				'post_type'      => 'page',
    				'comment_status' => 'closed',
    				'ping_status'    => 'closed',
    				'post_content'   => stripslashes( get_site_option( 'supporter_message' ) ),
    	'post_author' => $admin_id, // Add this line
    			) );
    
    // Code here
    
    restore_current_blog();
    
    // Code here

    About the problem that the page is recreated again is, I think, that the following function has no effect:
    $this->update_setting( 'checkout_page', $id );

    I suspect this because 'checkout_page' has never been assigned within the settings array, and is thus created by chance.
    I'm looking at 'function get_default_settings_array()' for this information. But I'm unsure what that function does, as I'm awake now for a good 17 hours.

    Well, that's all I can give you for now :slight_smile:

    Hope this helps!

    EDIT:

    Looking at https://core.trac.wordpress.org/browser/tags/4.3.1/src/wp-includes/post.php#L3128

    I can see that the post_author is indeed assigned to the "get_current_user_id()", whoever that may be :wink: This is not 'safe' with these kind of actions! D:

  • Sybre Waaijer
    • The Incredible Code Injector

    I think I know how to reproduce this, but it's very time consuming:
    1. Get a server, with the 2014 version of Pro Sites installed.
    2. Set up everything :smiley:
    3. Install static opcode caching, where new files don't work until the server / service is restarted
    4. Update pro sites, now pro sites is going to handle the options differently, after restart.
    5. Delete the pro-sites page
    6. Restart the opcode service, and get a snack.
    7. Now someone else logs in on your multisite.
    8. Voila, random user has 'inserted' your post :smiley:

    As you can see, many assume that the current user on activation will be the one with manage_options rights, but with caching, it's not always the case. Keep that in mind: close all doors and don't take things for chance :smiley: With PHP anyone can execute the code, even Google Bot who just wanted to take a peek.

    It's a good thing WordPress has closed many doors, but I think this one is left open for vulnerability. Did I just discover my first WordPress hack? D:

    Thanks and have a wonderful sunday ^^

    EDIT:
    Opened ticket at WP core trac on this issue too: https://core.trac.wordpress.org/ticket/34253

  • Adam Czajczyk
    • Support Gorilla

    Hello Sybre!

    Thanks for your feedback, this is very useful and descriptive information.

    Unfortunately I'm not able to reproduce those steps, having no access to the server that would let me use opcode cache at hand, so I'm forwarding this to the developers. I hope they'll be able to test this and hopefully solve the issue.

    Cheers,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.