You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Florian Walter <fw...@Veracode.com.INVALID> on 2023/01/11 11:30:15 UTC
Re: [EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
Hi Apache Security team and Xalan Dev Team,
I haven’t heard back so wondering if there is anything else you need from my end regarding the below mentioned XXE vulnerabilities in Apache Xalan?
Thank you,
Florian Walter
Florian Walter // Senior Application Security Consultant
[cid1650821754*image001.jpg@01D85876.FCE5BF50]
From: Florian Walter <fw...@Veracode.com>
Date: Monday, 19. December 2022 at 16:10
To: Apache Security Team <se...@apache.org>
Subject: Re: [EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
Hi there,
Agreed, XML parsers do provide multiple methods for blocking external entities, but none of them are implemented in Xalan.
It is the responsibility of Xalan to ensure the security of its XML-parsing functions. This means making sure that XML is parsed securely. XXE vulnerabilities can allow attackers to gain access to sensitive information and potentially compromise entire systems.
I would strongly recommend disabling doctypes in Xalan by configuring `DocumentBuilderFactory` (and `TransformerFactory`) in a secure way. This would mean the following:
// disable doc types
FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);
// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
And to protect a `TransformerFactory` from XXE, do this:
TransformerFactory tf = TransformerFactory.newInstance();
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");
This would make sure that every user of Xalan is protected from XXE.
Thank you,
Florian Walter
Florian Walter // Senior Application Security Consultant
[cid1650821754*image001.jpg@01D85876.FCE5BF50]
From: engelen@gsuite.cloud.apache.org <en...@gsuite.cloud.apache.org> on behalf of Apache Security Team <se...@apache.org>
Date: Thursday, 15. December 2022 at 09:58
To: Florian Walter <fw...@Veracode.com>
Subject: [EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
This email originated from outside of Veracode.
________________________________
Hello Florian,
XML parsers provides multiple methods for blocking access to external entities and for disallowing DOCTYPE declarations. Xerces and Xalan do what the XML specs require by default. It is up to the downstream user of Xalan to block/reject these constructs where appropriate.
---------- Original message ---------
From: Florian Walter
Date: Tue, Dec 13, 2022 at 5:44 PM
Subject: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
To: security@apache.org<ma...@apache.org> <se...@apache.org>>
Dear Apache Security Team,
I would like to report several XXE vulnerabilities in Apache Xalan-j 2.7.2 (i.e., the latest version).
The reason I am reaching out to you instead of the Xalan Project itself is that the “Security” link on https://xalan.apache.org/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxalan.apache.org%2F&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QhGtuE0zOuXnefPu%2Fnm%2FpZlaP1dMCqyF7X%2BqxHrq3kQ%3D&reserved=0> points to the main Apache Security page (https://www.apache.org/security/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Fsecurity%2F&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ffGbc6WH0i3w1aOpy%2BC4wY9yCAY%2Fofbb48vYJr%2F0aZI%3D&reserved=0>). Please let me know if there is a more appropriate contact for the issue.
Vulnerability Description:
None of the XML parsers in the whole project is configured in a way that would prevent XXE. XXE generally allows an attacker to extract arbitrary files and perform SSRF.
The only configuration I can find to lock down the XML parsers is `DocumentBuilderFactory.setFeature("http://javax.xml.XMLConstants/feature/secure-processing<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavax.xml.xmlconstants%2Ffeature%2Fsecure-processing&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zy5Ss4ru2i%2FmqA%2FEr6Ynp21QQZcC%2BK9ufQX8Dd3qOWY%3D&reserved=0>", true);` (the same is also applied on all `TransformerFactory` objects being used). However, this feature does not prevent XXE as has been pointed out by several security researchers (see e.g. https://www.blackhat.com/docs/us-15/materials/us-15-Wang-FileCry-The-New-Age-Of-XXE-java-wp.pdf<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.blackhat.com%2Fdocs%2Fus-15%2Fmaterials%2Fus-15-Wang-FileCry-The-New-Age-Of-XXE-java-wp.pdf&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VSbaw5q1V8fgfMYmLLVVR5XmerbOH6%2FGvNR5wsoHsSg%3D&reserved=0>, section “Insufficient Recommendations”).
I also created a PoC that clearly demonstrates that `secure-processing` does not prevent XXE: https://github.com/fw10/Secure-Processing-XXE-Tests-Java<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffw10%2FSecure-Processing-XXE-Tests-Java&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Sujvjzkt73gfVSTUqjS0I3zljKhexOOh%2F%2FLzMlbsxi0%3D&reserved=0>.
Attack PoC:
As an attack PoC, one can e.g. use the “SimpleTransform” example provided by the Xalan-j project itself (https://github.com/apache/xalan-j/tree/trunk/samples/SimpleTransform<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fxalan-j%2Ftree%2Ftrunk%2Fsamples%2FSimpleTransform&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q7Gz9teDDXiDA8WwJTOiGaLgoTxPCVbI3tHhNi8W5uU%3D&reserved=0>), which is one of the examples that shows how Xalan may be used. This example takes in `birds.xml` and outputs `birds.out`. To exploit this, attacker could e.g. inject the following standard XXE payload:
[cid:18514ff198a4cff311]
Upon running `Java SimpleTransform`, the `birds.out` file contains the `/etc/passwd` file:
[cid:18514ff198b5b16b22]
This proves that our XXE payload triggers. It looks like the same attack can be applied to ANY other (XML-parsing) functionality within Xalan, as I can’t see any securely configured XML parser anywhere in the source code.
Remediation:
To remediate the issue, the suggestion would be to follow the OWASP guidelines on XXE: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcheatsheetseries.owasp.org%2Fcheatsheets%2FXML_External_Entity_Prevention_Cheat_Sheet.html%23jaxp-documentbuilderfactory-saxparserfactory-and-dom4j&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y%2Bhj5mUMsfZHgrslheVhaFaar5oN%2BlyzgCUHFHit8yg%3D&reserved=0>.
Thank you,
Florian Walter
Florian Walter // Senior Application Security Consultant
[cid1650821754*image001.jpg@01D85876.FCE5BF50]
Re: [EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
Posted by Gary Gregory <ga...@gmail.com>.
Your question was answered on December 15 in this thread.
Gary
On Wed, Jan 11, 2023, 07:42 Florian Walter <fw...@veracode.com.invalid>
wrote:
> Hi Apache Security team and Xalan Dev Team,
>
>
>
> I haven’t heard back so wondering if there is anything else you need from
> my end regarding the below mentioned XXE vulnerabilities in Apache Xalan?
>
>
>
> Thank you,
>
> Florian Walter
>
>
>
> Florian Walter // Senior Application Security Consultant
>
>
>
> [image: cid1650821754*image001.jpg@01D85876.FCE5BF50]
>
>
>
> *From: *Florian Walter <fw...@Veracode.com>
> *Date: *Monday, 19. December 2022 at 16:10
> *To: *Apache Security Team <se...@apache.org>
> *Subject: *Re: [EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache
> Xalan-j 2.7.2
>
> Hi there,
>
>
>
> Agreed, XML parsers do provide multiple methods for blocking external
> entities, but none of them are implemented in Xalan.
>
>
>
> It is the responsibility of Xalan to ensure the security of its
> XML-parsing functions. This means making sure that XML is parsed securely.
> XXE vulnerabilities can allow attackers to gain access to sensitive
> information and potentially compromise entire systems.
>
>
>
> I would strongly recommend disabling doctypes in Xalan by configuring
> `DocumentBuilderFactory` (and `TransformerFactory`) in a secure way. This
> would mean the following:
>
>
>
> * // disable doc types*
>
> * FEATURE = "http://apache.org/xml/features/disallow-doctype-decl
> <http://apache.org/xml/features/disallow-doctype-decl>";*
>
> * dbf.setFeature(FEATURE, true);*
>
>
>
> *// and these as well, per Timothy Morgan's 2014 paper: "XML Schema,
> DTD, and Entity Attacks"*
>
> * dbf.setXIncludeAware(false);*
>
> * dbf.setExpandEntityReferences(false);*
>
>
>
> And to protect a `TransformerFactory` from XXE, do this:
>
>
>
> *TransformerFactory tf = TransformerFactory.newInstance();*
>
> *tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");*
>
> *tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");*
>
>
>
>
>
> This would make sure that every user of Xalan is protected from XXE.
>
>
>
> Thank you,
>
> Florian Walter
>
>
>
> Florian Walter // Senior Application Security Consultant
>
>
>
> [image: cid1650821754*image001.jpg@01D85876.FCE5BF50]
>
>
>
> *From: *engelen@gsuite.cloud.apache.org <en...@gsuite.cloud.apache.org>
> on behalf of Apache Security Team <se...@apache.org>
> *Date: *Thursday, 15. December 2022 at 09:58
> *To: *Florian Walter <fw...@Veracode.com>
> *Subject: *[EXTERNAL] Fwd: Fwd: Several XXE Vulnerabilities in Apache
> Xalan-j 2.7.2
>
> *This email originated from outside of Veracode.*
>
>
> ------------------------------
>
> Hello Florian,
>
>
>
> XML parsers provides multiple methods for blocking access to external
> entities and for disallowing DOCTYPE declarations. Xerces and Xalan do what
> the XML specs require by default. It is up to the downstream user of Xalan
> to block/reject these constructs where appropriate.
>
>
>
> ---------- Original message ---------
> From: *Florian Walter*
> Date: Tue, Dec 13, 2022 at 5:44 PM
> Subject: Several XXE Vulnerabilities in Apache Xalan-j 2.7.2
> To: security@apache.org <se...@apache.org>
>
>
>
> Dear Apache Security Team,
>
>
>
> I would like to report *several XXE vulnerabilities* in *Apache Xalan-j
> 2.7.2* (i.e., the latest version).
>
>
>
> The reason I am reaching out to you instead of the Xalan Project itself is
> that the “Security” link on https://xalan.apache.org/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxalan.apache.org%2F&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QhGtuE0zOuXnefPu%2Fnm%2FpZlaP1dMCqyF7X%2BqxHrq3kQ%3D&reserved=0>
> points to the main Apache Security page (https://www.apache.org/security/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Fsecurity%2F&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ffGbc6WH0i3w1aOpy%2BC4wY9yCAY%2Fofbb48vYJr%2F0aZI%3D&reserved=0>).
> Please let me know if there is a more appropriate contact for the issue.
>
>
>
>
>
> *Vulnerability Description:*
>
>
>
> None of the XML parsers in the whole project is configured in a way that
> would prevent XXE. XXE generally allows an attacker to extract arbitrary
> files and perform SSRF.
>
>
>
> The only configuration I can find to lock down the XML parsers is
> `DocumentBuilderFactory.setFeature("
> http://javax.xml.XMLConstants/feature/secure-processing
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavax.xml.xmlconstants%2Ffeature%2Fsecure-processing&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zy5Ss4ru2i%2FmqA%2FEr6Ynp21QQZcC%2BK9ufQX8Dd3qOWY%3D&reserved=0>",
> true);` (the same is also applied on all `TransformerFactory` objects being
> used). However, this feature does not prevent XXE as has been pointed out
> by several security researchers (see e.g.
> https://www.blackhat.com/docs/us-15/materials/us-15-Wang-FileCry-The-New-Age-Of-XXE-java-wp.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.blackhat.com%2Fdocs%2Fus-15%2Fmaterials%2Fus-15-Wang-FileCry-The-New-Age-Of-XXE-java-wp.pdf&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VSbaw5q1V8fgfMYmLLVVR5XmerbOH6%2FGvNR5wsoHsSg%3D&reserved=0>,
> section “Insufficient Recommendations”).
>
>
>
> I also created a PoC that clearly demonstrates that `secure-processing`
> does not prevent XXE:
> https://github.com/fw10/Secure-Processing-XXE-Tests-Java
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffw10%2FSecure-Processing-XXE-Tests-Java&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Sujvjzkt73gfVSTUqjS0I3zljKhexOOh%2F%2FLzMlbsxi0%3D&reserved=0>.
>
>
>
>
>
>
> *Attack PoC:*
>
>
>
> As an attack PoC, one can e.g. use the “SimpleTransform” example provided
> by the Xalan-j project itself (
> https://github.com/apache/xalan-j/tree/trunk/samples/SimpleTransform
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fxalan-j%2Ftree%2Ftrunk%2Fsamples%2FSimpleTransform&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q7Gz9teDDXiDA8WwJTOiGaLgoTxPCVbI3tHhNi8W5uU%3D&reserved=0>),
> which is one of the examples that shows how Xalan may be used. This example
> takes in `birds.xml` and outputs `birds.out`. To exploit this, attacker
> could e.g. inject the following standard XXE payload:
>
>
>
>
>
> Upon running `Java SimpleTransform`, the `birds.out` file contains the
> `/etc/passwd` file:
>
>
>
>
>
>
>
> This proves that our XXE payload triggers. It looks like the same attack
> can be applied to *ANY* other (XML-parsing) functionality within Xalan,
> as I can’t see any securely configured XML parser anywhere in the source
> code.
>
>
>
>
>
> *Remediation:*
>
>
>
> To remediate the issue, the suggestion would be to follow the OWASP
> guidelines on XXE:
> https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcheatsheetseries.owasp.org%2Fcheatsheets%2FXML_External_Entity_Prevention_Cheat_Sheet.html%23jaxp-documentbuilderfactory-saxparserfactory-and-dom4j&data=05%7C01%7Cfwalter%40veracode.com%7C04e60a49837d4e7bf5c708dade7a523d%7C3b627b68f21c4ed79fe3698efdedbe21%7C0%7C0%7C638066915332528345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y%2Bhj5mUMsfZHgrslheVhaFaar5oN%2BlyzgCUHFHit8yg%3D&reserved=0>.
>
>
>
>
>
>
> Thank you,
>
> Florian Walter
>
>
>
> Florian Walter // Senior Application Security Consultant
>
>
>
> [image: cid1650821754*image001.jpg@01D85876.FCE5BF50]
>