New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XML Injection Denial of Service #1141
Comments
|
Thanks for the report @prodigysml. The issue is as critical as any import (e.g. plugins) from untrusted sources, but a validation wouldn't hurt. SimpleXML does not seem to provide a validator, so we'd need to switch to DOMDocument instead. |
|
Actually, |
|
@bloatware yes they have protected against the XML bomb to a certain extent. It is still pretty simple to recreate an XML bomb. All we have to do is ensure that we don't call an entity more than 4 times. |
|
Not sure the protection is that simple, mind providing a bomb example? |
|
Sure thing @bloatware Example XML code is below: <?xml version="1.0"?>
<!DOCTYPE foo [
<!ELEMENT foo (#PCDATA)>
<!ENTITY l "lol" >
<!ENTITY a "dfszfhsauyfghdusyfgsuyfgsiyfgsdyfgseuyfgesuyfgesiugfseugyfgaeyfaegufeuigyyusadgffyyusdgrdfvgesiyuesjuguishd e sui sgdfuisrg uy f gsfure grg sud yhsd rguysege sejhges xd u esy sy ugse rfsue gyysd fghsd gfuyes">
<!ENTITY lol "&l;">
<!ENTITY lol9 "&lol;&lol;&lol;&lol;">
<!ENTITY aa "&a;&a;&a;&a;">
<!ENTITY lol10 "&lol9;&aa;">
<!ENTITY xxe "&lol10;">
]>
<foo>&xxe;</foo>As you can see, we dont have any restrictions on the length of an entity and the number of entities. We have a restriction on the number of times an entity is called. This can easily be expanded to create a DoS scenario. Then only thing is, you will be sending a large payload yourself, but that still isn't that bad when considering you are putting aside specific resources to DoS the system. Hope that helps! :) |
|
Thanks @prodigysml, I know it works in theory, just am not able to create a bomb without sending a really large payload. The server seems to defend itself against exponential attacks, but is probably vulnerable to polynomial ones. I guess we will just prohibit DOCTYPE declarations atm. |
|
I don't think there's much else we can do here. Everyone concur? Or can we do more to mitigate this? |
|
Schema validation seems too restrictive, we don't know what kind of documents could be imported in the future. I guess there is nothing we can do if a user imports weird files (XML or whatever) into his txp install. |
|
Shall we close this then, and get 4.7.0 beta out? |
|
Postpone it to 4.8, perhaps? Custom fields will be a big change, I guess, including XML import. |
|
Yep, let’s get beta out ASAP. This can wait. |
We also recognize being vulnerable to uploading a specially crafted PHP file to a special directory or installing a specially crafted plugin or whatever harmful action a site admin decides to undertake. Any ideas how to fix it? |
|
Is there any fix for this issue? |
|
@NicoleG25 the 'issue' is of the same order of criticality that uploading a harmful php file or plugin. We currently use XML import only on setup for data provided with txp distribution, which is safe. |
|
@bloatware meaning you disagree with the assignment of the CVE-ID? Thanks in advance! |
|
@NicoleG25 there is (currently) no plan to fix it since there is (currently) nothing to fix. The only persons able to exploit this 'vulnerability' are txp site admins (or hackers capable to upload files to txp system directories). But they have full powers anyway and don't need this hack to destroy the site. Thank you for your interest. |
Expected behaviour
Validate XML import against a schema
Actual behaviour
Processes the XML bomb provided
Steps to reproduce
Import an XML file with the following content:
This shows how we can make the server consume memory when parsing the XML. This can be done to eventually exhaust the entire server's memory (depending on configuration) and create a denial of service scenario.
The lines of code vulnerable are given below:
textpattern/textpattern/vendors/Textpattern/Import/TxpXML.php
Line 101 in 1a84949
If schema validation is added to the method, the issue should be resolved. This will also require ensuring entities are not within the XML file too.
The text was updated successfully, but these errors were encountered: