@Mike, I don't mean to hijack this thread but could you elaborate on what is 'insecure' with php/xml? Was it the rendering or the importing (feed reader) or is it the entire php xml parser?
The idea is similar to the
Billion Laughs (or ZIP bomb, what have you) attack, except instead of defining nested elements you define one really big element then repeat that really big element by a really big amount.
In SGML (this includes HTML and XML), you can define your own tags to be parsed by the SGML parser (this is why you see <!DOCTYPE w3.org/something.dtd> at the start of the HTML document); this is the backbone of HTML and is a very useful feature in XML.
To define one, you use:
Code:
<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE author [
<!ELEMENT author (#PCDATA)>
<!ENTITY js "Jo Smith">
]>
<author>&js;</author>
As you can probably already guess, this defines an <author> tag and &js; will be replaced by "Jo Smith", producing the final output of <author>Jo Smith</author>. Now if we do this:
Code:
<?xml version="1.0"?>
<!DOCTYPE malicious [
<!ELEMENT malicious (#PCDATA)>
<!ENTITY x "InsertAFewHundredBytesToAFewKilobyteOfDataHere">
]>
<malicious>&x;&x;&x;&x;&x;&x;&x;&x;&x;...</malicious>
The XML parser will spend all its memory trying to get the final tag, which will exhaust the 128MB of memory XenForo allocates by default very quickly and use up a lot of CPU cycles - this is how a machine is brought down.
To fix this, there are a few approaches:
1. Validate the XML by schema using
schemaValidate: Requires definition of all XML documents. Both Atom and RSS have one; XF may need some additional code to make this happen without breaking addons.
2. Stop execution if entity definitions are detected
3. Ignore entities definition when parsing: Will mean that support for PHP 5.2.4 - 5.2.11 will need to be dropped since the
relevant function is only introduced in 5.2.11
XenForo chose to employ ZF1's (undocumented) Zend_XML_Security class, which does item 2 and 3.
Additionally, there is also a related exploit that can
power XSS attacks, meaning an attacker can display arbitary JS or even PHP code. This is not directly related to this attack and I'm not sure how much XenForo (or ZF, since the Reader code is largely ZF's code) does to prevent rogue XML data.
