WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3142 closed defect (bug) (fixed)

user_edit.php vulnerable: User can spy out metadata of other users

Reported by: adapter Owned by:
Milestone: Priority: high
Severity: major Version: 2.0.4
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

Every logged in user can spy out the metadata of all other users by typing in the URL /wp-admin/user-edit.php?user_id=XXX irrespective if he has the right to do this or not. If not in fact there will be shown the error message "You do not have permission to edit this user." but after that message the complete form with all data will also be shown.

Attachments (3)

user-edit.php (6.6 KB) - added by adapter 8 years ago.
3142-2.0.5.diff (586 bytes) - added by westi 8 years ago.
Fix for 2.0.x
3142-trunk.diff (613 bytes) - added by westi 8 years ago.
Fix for trunk

Download all attachments as: .zip

Change History (16)

comment:1 westi8 years ago

  • Milestone set to 2.1

I can't reproduce this.

You can edit/see your own profile this way but otherwise the edit_users cap check blocks you from editing someone else.

comment:2 adapter8 years ago

That could be another bug.

The whole story: user-edit didn't work on my wordpress-blog www.poplog.de. Tried to edit users other than mine, but always I got the edit-form for my user though I'm the admin. Checked the code of user-edit.php and saw that there are two variables in use:
$user_id (ID of the user to edit)
and
$user_ID (ID of the user looged in = in this case: admin-ID = 1)
The values of both were 1 irrespective the value of user_id in the query string.
Maybe configuration of PHP is the reason for this. PHP on this server doesn't work case sensitive. Therefore I found the bug described above.

comment:3 foolswisdom8 years ago

Hi adapter, I have not heard of PHP that is not case sensitive for variables. What PHP are you running?

comment:4 adapter8 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Thanks foolswisdom. You're right. This bug was caused by my-hacks.php. In one of my blogs I've implemented a user-tracking-functions and there I'm using $user_id for the ID of the user logged in. Sorry!

But I'm running several installations of wordpress, some of them without any changes and in all of them you can spy out user-data.

But it's easy to patch: Add this line of code in line 71 of user-edit.php:

<?php if (!current_user_can('edit_users')) { include('admin-footer.php'); die(); } ?>

adapter8 years ago

comment:5 foolswisdom8 years ago

  • Keywords bug vulnerability removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi Adapter,

Thank you for participating in WordPress!

Please do not mark bugs as FIXED. That is done when a fix is checked into the official source tree.

Please try to be as concise as possible. For example when you say "this bug" I do not know if you are referring to the originally reported problem or, my guess, what you thought was causing the "case insensitivity".

Please do not attach files, but attach a diff.

ENV: WP 2.0.4

Using 2 "subscribers", I have not been able to reproduce the problem you describe.

Below "You do not have permission to edit this user." the users *own* data is displayed. I think this experience is a bit awkward (and a new bug could be created), but this is not the bug you describe.

comment:6 foolswisdom8 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

Closing as WORKSFORME. adapter please update with detailed steps if have reproducible scenario on clean install.

comment:7 adapter8 years ago

That's strange.

Yesterday I downloaded the current release WP 2.0.4 and installed it here: http://test.poplog.de. There you can register, log in and call http://test.poplog.de/wp-admin/user-edit.php?user_id=1. You will see admin's data.

comment:8 westi8 years ago

  • Keywords has-patch added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Hmm - I can now reproduce this both on your test blog and my test 2.0.4 install.

I believe this affects 2.0.4 and 2.1 so is a candidate for a fictional 2.0.5 as a security release.

I'm attaching patches for 2.0.x and trunk.

westi8 years ago

Fix for 2.0.x

westi8 years ago

Fix for trunk

comment:9 ryan8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [4216]) Don't show user form without privs. Props westi. fixes #3142

comment:10 foolswisdom8 years ago

Thanks Adapter. I can also now confirm the bug -- also not sure what I was doing before. Thank you for your patience and sticking with it.

I have also verified the fix.

comment:11 ryan8 years ago

(In [4244]) Don't show user form without privs. Props westi. fixes #3142

comment:12 foolswisdom8 years ago

  • Milestone changed from 2.1 to 2.0.5

comment:13 anonymous7 years ago

  • Milestone 2.0.5 deleted

Milestone 2.0.5 deleted

Note: See TracTickets for help on using tickets.