Ticket #3142 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

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

Reported by: adapter Assigned to: anonymous
Priority: high Milestone:
Component: Administration Version: 2.0.4
Severity: major Keywords: has-patch
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

user-edit.php (6.6 kB) - added by adapter on 09/23/06 13:06:39.
3142-2.0.5.diff (0.6 kB) - added by westi on 09/24/06 09:11:58.
Fix for 2.0.x
3142-trunk.diff (0.6 kB) - added by westi on 09/24/06 09:12:16.
Fix for trunk

Change History

09/18/06 17:20:21 changed by westi

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

09/18/06 18:30:38 changed by adapter

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.

09/22/06 00:43:31 changed by foolswisdom

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

09/23/06 13:04:53 changed by adapter

  • status changed from new to closed.
  • resolution set to fixed.

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(); } ?>

09/23/06 13:06:39 changed by adapter

  • attachment user-edit.php added.

09/23/06 17:26:40 changed by foolswisdom

  • keywords deleted.
  • status changed from closed to reopened.
  • resolution deleted.

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.

09/24/06 00:54:27 changed by foolswisdom

  • status changed from reopened to closed.
  • resolution set to worksforme.

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

09/24/06 08:42:33 changed by adapter

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.

09/24/06 09:11:01 changed by westi

  • keywords set to has-patch.
  • status changed from closed to reopened.
  • resolution deleted.

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.

09/24/06 09:11:58 changed by westi

  • attachment 3142-2.0.5.diff added.

Fix for 2.0.x

09/24/06 09:12:16 changed by westi

  • attachment 3142-trunk.diff added.

Fix for trunk

09/24/06 10:09:01 changed by ryan

  • status changed from reopened to closed.
  • resolution set to fixed.

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

09/25/06 00:34:23 changed by foolswisdom

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.

09/25/06 02:54:26 changed by ryan

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

09/25/06 04:23:04 changed by foolswisdom

  • milestone changed from 2.1 to 2.0.5.

11/30/06 19:41:51 changed by

  • milestone deleted.

Milestone 2.0.5 deleted