Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Security Vulnerability issue using XML Entity Expansion

    Hi,

    Our client has identified a security vulnerability issue using XML Entity Expansion in our Smart client UI.

    This is the issue he has reported :

    The application is configured to process recursively defined XML entities, which may lead to a denial of service condition if a sufficiently large set of recursive entity references is defined in the XML request.

    An XML entity or named entity is an association between a reference (the entity) and a string. When the XML parser sees an entity in the body of a document, it performs a lookup to find the string associated with the entity. Once found, this string is substituted for the entity name in the document body.

    As an example, consider the following XML file: <!DOCTYPE root [ <!ENTITY ha SYSTEM "Hello World!"> ]> <root>&ha;</root>
    The XML parser will first load the entity definition in memory and then, when it sees “&ha”; it will replace it with the definition of the entity, which in this example is "Hello World!". Here is the resulting XML document in memory: <root>Hello World!</root>

    The application XML parser will also recursively expand Document Type Definition (DTD) entities while parsing XML documents. The XML entity expansion attack targets parser memory consumption by utilizing recursion in XML entity definitions. The following XML document DOCTYPE requires the parser to make approximately 257 recursions (2n+1 where n equals 128 here): <!DOCTYPE root [ <!ENTITY ha0 "content"> <!ENTITY ha1 "&ha0; &ha0;"> <!ENTITY ha2 "&ha1; &ha1;"> … <!ENTITY ha128 '&ha127; &ha127;'> ]> <root>&ha128;</root>

    A malicious user may be able to supply a relatively small XML document containing a large number of internal recursive DTD (Document Type Definition) references which would be expanded by the parser into a large quantity of text in memory. The time required to process these DTD references and the large amount of memory consumed by the process may lead to a denial of service condition on applications that utilize the XML parser. During such an attack, legitimate application users would experience extensive delays or be completely unable to access the application.


    Remediation:

    Depending on system requirements, one of the following options is available to prevent XML entity expansion attacks:
    * Disable entity expansion when possible.
    * Limit the number of entity reference nodes that the parser can expand.
    * Limit the number of characters entities can expand to.

    Do you have any fix to resolve this issue in SmartClient ?

    #2
    Hi satya_paul,

    isn't it this issue? You should really always post the used version.

    Best regards
    Blama

    Comment


      #3
      We are using Smart Client 10_0. Do you have fix for Billion Laughs in this version ?

      Comment


        #4
        Hi,

        I'm also just a user. Just search the forums for "Billion Laughs". If it is in 9.0 I assume it is also in 10.0 - if you a using a recent build.

        Best regards
        Blama

        Comment


          #5
          Hi Isomorphic Administrator,

          Is there any way we could reach you. We want a fix for Billion Laughs issue for Smart Client 10_0 Enterprise version. This is very critical for us. Please reply.

          Comment


            #6
            This is a Severity 1 issue and blocker for our customer to go live. Please reply us how we could solve this issue in SmartClient v10_0 Enterprise. Is there any patch we can apply on top of our existing fix and test it out ? We are waiting for your reply. Please reply back ASAP.

            Comment


              #7
              You've already been told that a workaround for this was applied as far back as 9.0. 9.0 is less than 10.0. What are you still asking about?

              Comment


                #8
                Our customer has recreated the issue in Smart Client version 10_0 Enterprise edition. So, I am looking for a reply whether this has been fixed in any particular fixpack of 10_0.

                Comment


                  #9
                  Hi Isomorphic Administrator,

                  Please provide us in which nightly build of 10.0, the billion laughs issue is resolved. Also, we want to know the nightly build information of the Smartclient 10.0 version which we are using. The Smartclient apis in our product says 'Jul 16 2015' which is around 20 months old. How to find the nightly build information of Smartclient ? In which file, we can get this information ?

                  Please help us.

                  Comment


                    #10
                    To update, download the latest patched build of 10.0 from smartclient.com/builds.

                    Be sure to read the text at smartclient.com/builds as well.

                    Comment


                      #11
                      Hi Isomorphic Administrator,

                      I took the latest version of SmartClient version10_0 Enterprise Edition SmartClient_v100p_2017-03-06_Enterprise from link : http://www.smartclient.com/product/d...erReleases.jsp. I am able to recreate the issue there. Hence, the issue is not resolved. I have emailed support@isomorphic.com with recreation steps. Please check.

                      Comment


                        #12
                        Please stop simultaneously posting and sending emails to various addresses. Posting here is sufficient.

                        As we've covered, we've had multiple customers confirm this issue as fixed. So your next step is to confirm you've actually deployed the new version. In particular, carefully check that the server-side .jars you are using are actually the new .jars from the patched version you downloaded.

                        Comment


                          #13
                          Hi, Please check whether the recreation steps I sent works for you with latest build of SmartClient v10_0 Enterprise Edition. It doesn't work for me.

                          Comment


                            #14
                            Your steps for reproducing the Billion Laughs exploit (from your email) are incorrect. When XML entity expansion is disabled, the expected result of submitting XML with entity expansions is that it is treated as malformed XML and an error is logged on the server. This is what happens, and you are interpreting the 2 minute delay in your tool as indicating server-side processing is going on, but it's not. Just check the server-side logs to see the error.

                            You can also use any kind of task monitoring tool to verify that the server process isn't consuming vast amounts of memory and CPU, as would be expected if the exploit were actually working.

                            Comment


                              #15
                              Thanks for the reply. Is there any specific trace, I can look for in javascript:showLog() client side window to confirm that XML processing is disabled. Also, is it possible to enable certain trace in Isomorphic to confirm the behavior in server side ?

                              Comment

                              Working...
                              X