Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#5313 closed defect (bug) (fixed)

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

Reported by: columcille's profile Columcille Owned by: josephscott's profile 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 .

http://wordpress.org/support/topic/134928/page/2#post-686510
http://www.theseekerblog.com/?p=284
http://www.village-idiot.org/archives/2008/02/02/wordpress-232-exploit-confirmed/

Attachments (3)

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

Download all attachments as: .zip

Change History (27)

#1 @Columcille
17 years ago

  • Component changed from General to Security

#2 @lloydbudd
17 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.

#3 @pishmishy
17 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.

#4 @cbdilger
17 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:77.70.106.72 - - [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.

#5 @pishmishy
17 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

#6 @cbdilger
17 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.

#7 @lloydbudd
17 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.

#8 follow-up: @thee17
17 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.

#9 @thee17
17 years ago

  • Milestone changed from 2.6 to 2.5

#10 in reply to: ↑ 8 @lloydbudd
17 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.
http://wordpress.org/support/topic/134928/page/2#post-686510
http://www.village-idiot.org/archives/2008/02/02/wordpress-232-exploit-confirmed/
http://www.theseekerblog.com/?p=284

Updating description.

#11 @lloydbudd
17 years ago

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

#12 @josephscott
17 years ago

Add cap check

#13 @matt
17 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.

#14 @lloydbudd
17 years ago

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

#15 @ryan
17 years ago

  • Milestone changed from 2.5 to 2.3.3

#16 @ryan
17 years ago

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

#17 @ryan
17 years ago

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

@josephscott
17 years ago

Make sure cap checks happen

#19 @cbdilger
17 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

#19 @ryan
17 years ago

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

@josephscott
17 years ago

Patch against 2.3-branch

#20 @ryan
17 years ago

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

#21 @ryan
17 years ago

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

#22 @ryan
17 years ago

  • Milestone changed from 2.3.4 to 2.9

Milestone 2.3.4 deleted

#23 @scribu
17 years ago

  • Milestone 2.9 deleted

#24 @westi
17 years ago

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