DoS in wp-trackbacks

[gomex]

The exploit: ​http://codes.zerial.org/php/wp-trackbacks_dos.phps

Execution:

$ while /bin/true; do php test.php ​http://target.bom/wordpress; done
hit!
hit!
hit!
hit!
hit!
hit!
hit!
hit!
hit!
hit!

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

down!!

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

[scribu]

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

[g30rg3x]

Already addressed in changeset [12057]

[Otto42]

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:

charset[]='UTF-8'
charset[]='UTF-8'
charset[]='UTF-8'
... a few thousand more times ...
charset[]='UTF-8'
other_standard_stuff='whatever'
...

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.

[aperez]

I made a quick review of the trackback specification (​http://www.sixapart.com/pronet/docs/trackback_spec) 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.

[Otto42]

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.