Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#5313 closed defect (bug) (fixed)

no user checking if the "post_type" is set to page

Reported by: Columcille Owned by: josephscott
Milestone: 2.5 Priority: highest omg bbq
Severity: blocker Version: 2.3.1
Component: Security Keywords:
Focuses: Cc:

Description (last modified by lloydbudd)

There is no user checking if the "post_type" is set to page.

Feb 2, 2008 http://wordpress.org/support/topic/134928 now describes a security issue in xml-rpc:

Although this ticket has been open for 3 months, the previous description and the discussion here, on the forums, and elsewhere did not identify the vector.

A person has to already have an account on your blog, or be able to create an account (even just subscription) to abuse this bug.

WORKAROUND: if enabled, disable account creation including subscription to your blog, or temporarily delete the file xmlrpc.php .


Attachments (3)

xmlrpc.php.diff (677 bytes) - added by josephscott 8 years ago.
xmlrpc.php.2.diff (3.2 KB) - added by josephscott 8 years ago.
Make sure cap checks happen
2.3-xmlrpc.php.diff (3.2 KB) - added by josephscott 8 years ago.
Patch against 2.3-branch

Download all attachments as: .zip

Change History (27)

comment:1 @Columcille8 years ago

  • Component changed from General to Security

comment:2 @lloydbudd8 years ago

Copying DD32's forum comment here:

Can anyone take a read through their webservers access logs and look for anything suspect accessing the admin pages?
Also check for other users, and change the admin passwords.
It is hard to work out what is happening here without knowing where the problem is coming from.

comment:3 @pishmishy8 years ago

  • Owner changed from anonymous to pishmishy
  • Status changed from new to assigned

I've actually spotted this in a couple of installs but I can't tell if this came from the currently installed WordPress version has been around since an older install. If someone has mysql logs hanging around (binary or otherwise) it may be helpful if they are able to pick out when the code was inserted into the database. Something along the lines of

# mysqlbinlog mysql-bin.* | grep iframe

would do the trick.

comment:4 @cbdilger8 years ago

I don't have access to MySQL logs (shared hosting) but I found this in my webserver logs--there are 30 nearly identical entries over two days.

access.log.2007-11-29.gz: - - [29/Nov/2007:05:37:16 -0800] "POST /cbd/wp-admin/admin-ajax.php HTTP/1.1" 200 14 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)"

this is in the right time frame---three days after the post I wrote which was hit with the iframe.

I'll keep looking for other funny stuff. Any pointers appreciated. And I can provide logs for WordPressers to work with.

comment:5 @pishmishy8 years ago

I'm not sure an access within three days is too useful.
It appears what you're seeing is someone trying to exploit the vulnerability fixed in #4322

comment:6 @cbdilger8 years ago

I'm sorry, that wasn't clear. What I meant: since I wrote the post Nov 26 and didn't discover the injected iframe until Dec 10, the access to admin-ajax.php could have been involved. Thanks for letting me know it probably wasn't.

comment:7 @lloydbudd8 years ago

  • Milestone 2.5 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

Closing as invalid, because this bug does not have enough information to be resolved. Please open a new ticket with causal details, if you experience a similar issue.

comment:8 follow-up: @thee178 years ago

  • Milestone set to 2.6
  • Priority changed from high to highest omg bbq
  • Resolution invalid deleted
  • Severity changed from major to critical
  • Status changed from closed to reopened

Because the method of exploiting this was posted, this needs fixed and posibly fast.

Probably should be fixed in 2.3.3 as well.

comment:9 @thee178 years ago

  • Milestone changed from 2.6 to 2.5

comment:10 in reply to: ↑ 8 @lloydbudd8 years ago

  • Description modified (diff)
  • Owner changed from pishmishy to josephscott
  • Status changed from reopened to new

Replying to thee17:

Because the method of exploiting this was posted, this needs fixed and posibly fast.

Although the same support topic, it probably would have been better to open a new ticket, because it is difficult to confirm that the original issue is caused by this issue.

Also, it is benefitial at this point to explicitly including the details if not at least the links.

Updating description.

comment:11 @lloydbudd8 years ago

  • Description modified (diff)
  • Summary changed from iframe being injected to no user checking if the "post_type" is set to page

@josephscott8 years ago

comment:12 @josephscott8 years ago

Add cap check

comment:13 @matt8 years ago

I don't think the current patch addresses all the issues. There should be a definitive patch available tonight, and a release to follow.

comment:14 @lloydbudd8 years ago

  • Description modified (diff)
  • Severity changed from critical to blocker

comment:15 @ryan8 years ago

  • Milestone changed from 2.5 to 2.3.3

comment:16 @ryan8 years ago

(In [6709]) Add edit_page cap check. Props josephscott. see #5313

comment:17 @ryan8 years ago

(In [6710]) Add edit_page cap check. Props josephscott. see #5313

@josephscott8 years ago

Make sure cap checks happen

comment:19 @cbdilger8 years ago

I've had mysterious spam-type content added to posts, as I noted above ("iframe" content) and here ("noscript" content). And here's a similar issue ("noscript").

The support thread referenced by lloydbudd mentions users as part of the exploit. Has that been confirmed? I haven't had any unexplained user registrations to my weblog (I know all the registrants). In fact, in the times I've been hit, I haven't seen any new user registrations.

Thanks, Bradley

comment:19 @ryan8 years ago

(In [6714]) More cap checks from josephscott. see #5313

@josephscott8 years ago

Patch against 2.3-branch

comment:20 @ryan8 years ago

(In [6715]) More cap checks from josephscott. see #5313

comment:21 @ryan8 years ago

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

comment:22 @ryan7 years ago

  • Milestone changed from 2.3.4 to 2.9

Milestone 2.3.4 deleted

comment:23 @scribu7 years ago

  • Milestone 2.9 deleted

comment:24 @westi7 years ago

  • Milestone set to 2.5
Note: See TracTickets for help on using tickets.