Make WordPress Core

Opened 14 years ago

Closed 10 years ago

#10980 closed defect (bug) (fixed)

DoS in wp-trackbacks

Reported by: gomex's profile gomex Owned by: ryan's profile ryan
Milestone: 2.8.5 Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:


The exploit:


$ while /bin/true; do php test.php; done

Notice: fputs(): send of 8192 bytes failed with errno=11 Resource
temporarily unavailable


Load average: 22.07, 15.18, 8.58 (on target server)

Change History (10)

#1 @scribu
14 years ago

  • Component changed from General to Security
  • Owner set to ryan

#2 @scribu
14 years ago

  • Milestone changed from Unassigned to 2.9
  • Version set to 2.9

#3 @scribu
14 years ago

  • Milestone changed from 2.9 to 2.8.5
  • Version changed from 2.9 to 2.8.4

#4 @scribu
14 years ago

Tried the script on my own site (latest trunk). Ran it for ~5 minutes and nothing happened. The site is still up.

#5 @g30rg3x
14 years ago

  • Milestone 2.8.5 deleted
  • Priority changed from highest omg bbq to normal
  • Resolution set to fixed
  • Severity changed from major to trivial
  • Status changed from new to closed
  • Version 2.8.4 deleted

Already addressed in changeset [12057]

#6 @Otto42
14 years ago

  • Priority changed from normal to high
  • Resolution fixed deleted
  • Severity changed from trivial to critical
  • Status changed from closed to reopened

The patch in [12057] does not fix the problem. A trivial change to the exploit would still trigger it, even in 2.8.5.

If the exploit were to send an array using the php brackets method, then that array would not have commas or spaces in it, and the DOS attack would still succeed.

Imagine I sent this POST to the trackback.php file:

... a few thousand more times ...

In this case, the contents of $_POSTcharset? would be an array. That array would get a str_replace done on each element, but there wouldn't be any commas or spaces in them. The array then gets passed on to mb_convert_encoding, which triggers the underlying problem.

The underlying problem is that passing huge numbers of charsets to mb_convert_encoding breaks the thing. I can still pass those huge numbers using this manner.

There needs to be a check on the $_POSTcharset? to ensure that it's a string and not an array.

#7 @aperez
14 years ago

  • Cc aperez added

I made a quick review of the trackback specification ( and a charset parameter in the request body is *not* allowed. Charset *should* be specified in the HTTP Content-Type header instead. I suppose this is a leftover from old spec revisions, so probably charset handling could be removed from wp-trackback.php. If I am right PHP will happily take into account the HTTP header sent by the client, and act accordingly (please correct me if I am wrong).

If for some reason (e.g. compatibility with old clients) this is not a good idea, another option would be using iconv(), which does only accept a single destination encoding.

#8 @Otto42
14 years ago

  • Priority changed from high to normal
  • Severity changed from critical to normal

Correction: The behavior of "trim" prevents the array possibility from working in this case, however I get different results with different versions of PHP.

I suggest that this approach still be patched, as relying on undocumented (and unpredictable) behavior to prevent a security problem is not a great idea.

However, the issue is not a critical one, as I cannot find a way to exploit 2.8.5 in this manner as of yet. I still think it's possible, but it's not trivial to do.

#9 @scribu
14 years ago

  • Milestone set to Future Release

#10 @nacin
10 years ago

  • Milestone changed from Future Release to 2.8.5
  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.