Announcement

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

    CVE-2020-10683

    Hi Isomorphic.

    Regarding the following CVE.

    CVE-2020-10683
    dom4j before 2.0.3 and 2.1.x before 2.1.3 allows external DTDs and External Entities by default, which might enable XXE attacks. However, there is popular external documentation from OWASP showing how to enable the safe, non-default behavior in any application that uses dom4j.
    Can you confirm you are enabling the safe, non-default behavior as recommended by OWASP, for the dom4j-1.6.1.jar dependency?

    We would like to confirm there is no impact here.

    Thank you

    #2
    Yes, we long ago turned off the various vulnerable features for parsing network requests.

    Comment


      #3
      Thank you

      Comment


        #4
        Hi Isomorphic,

        There are two other open CVEs against the SmartGWT v12.1p third party dependency dom4j-1.6.1.jar.

        Can you please confirm you are not vulnerable to the following CVEs open against dom4j-1.6.1.jar?

        CVE-2018-1000632
        dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class: Element. Methods: addElement, addAttribute that can result in an attacker tampering with XML documents through XML injection. This attack appear to be exploitable via an attacker specifying attributes or elements in the XML document. This vulnerability appears to have been fixed in 2.1.1 or later.
        CVE-2023-45960
        An issue in dom4.j org.dom4.io.SAXReader v.2.1.4 and before allows a remote attacker to obtain sensitive
        information via the setFeature function. NOTE: the vendor and original reporter indicate that this is not a
        vulnerability because setFeature only sets features, which "can be safe in one case and unsafe in another."
        Thank you







        Comment


          #5
          This took a moment. You should not need this jar unless you are using Hibernate - are you?

          Even if the jar were present, it would be inactive if present unless you were using Hibernate. In addition, so far as we can tell, it would not be exploitable unless you allowed end users to write Hibernate configuration files or Hibernate mapping files (*.hbm.xml).

          Comment


            #6
            We do not use Hibernate so we will proceed with removing the dependency.

            Thank you

            Comment

            Working...
            X