[Python]: CWE-611: XXE

[jorgectf]

Query

Relevant PR: github/codeql#6112

Report

Parsing untrusted XML files with a weakly configured XML parser may lead to an XML External Entity (XXE) attack.
This type of attack uses external entity references to access arbitrary files on a system, carry out denial of
service, or server side request forgery. Even when the result of parsing is not returned to the user, out-of-band
data retrieval techniques may allow attackers to steal sensitive data. Denial of services can also be carried out
in this situation.

There are many XML parsers for Python, and most of them are vulnerable to XXE because their default settings enable
parsing of external entities. This query currently identifies vulnerable XML parsing from the following parsers:
xml.etree.ElementTree.XMLParser, lxml.etree.XMLParser, lxml.etree.get_default_parser,
xml.sax.make_parser.

• Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

Result(s)

New:

• • CVE-2021-44556
• • CVE-2021-44557

Already existing:

• CVE-2016-5851
• CVE-2020-10799
• CVE-2021-29421
• CVE-2013-1665

[ghsecuritylab]

Your submission is now in status Generate Query Results.

For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

[m-y-mo]

For the results that you included in this ticket, we recommend you reach out to the maintainer and suggest them to create GitHub Security Advisories and assign CVEs for these findings. By publishing security advisories, repository maintainers make it easier for their community to update package dependencies and research the impact of the security vulnerabilities. When they create a security advisory they can request a CVE identification number from GitHub. GitHub usually reviews the request within 72 hours. Read more at https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories
Thanks.

[ghsecuritylab]

Your submission is now in status FP Check.

For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

[jorgectf]

Hi @m-y-mo, apologies for the delay. I've just reached out to the maintainer. Thanks :)

[jorgectf]

Hi @m-y-mo, apologies for the delay. I've just reached out to the maintainer. Thanks :)

I'm not getting a reply, how should I proceed? Thanks. @m-y-mo

[m-y-mo]

@jorgectf
Thanks for the submission and sorry for the late reply. Although we normally require a CVE found by the query to accept an All-for-one submission, we have decided to make an exception in this case because the maintainer fixed the issue, even if they didn't answer to your CVE request.
Overall we found that the quality of the query is of a good standard, and the reason for the query to not find the included results is due to relevant remote sources not yet included in the CodeQL Python library. We're looking into improving this at the moment. As for software maintainers not responding to CVE request, unfortunately this is not uncommon and there is very little we can do to help unless the maintainers filed a CVE request via GitHub. In the future, I'd suggest either include an existing CVE that the query can find, (It can be an old one and it does not have to be found by you or discovered via CodeQL originally, as long as the CVE can be found by the query in the submission, it is OK), or wait until a CVE request is submitted before submitting to All-for-one. In general we do not encourage the inclusion of unfixed vulnerabilities in any of our bug bounty submission and doing so will lead to the submission being disqualified immediately.

[ghsecuritylab]

Your submission is now in status Query review.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

[jorgectf]

@m-y-mo Thank you for your reply :) and for making that decision.

I'm currently working on the CVE-related stuff for all of my submissions. However, MITRE is taking very long to process the requests (up to 6 month in some cases), so the bounty submissions may take some time to get CVEs added to them. I'd like to suggest thinking about another way of “proof” of the vulnerability while MITRE is processing it. Otherwise bounties' processes will be much slower.

[m-y-mo]

@jorgectf To apply for All-for-one, you don't need to find and report the CVE yourself. Any existing CVE that can be found by your query, whether or not they were found by CodeQL in the first place, can be included in the submission. The idea of All-for-one is not that the query finds new CVEs, but rather your query covers a category of vulnerabilities and is also general enough that they can be used to prevent similar issues in the future. To prove that this is the case, we've decided that the query should at least be able to find some existing vulnerabilities in open source software. So you don't need to find and apply for new CVEs when submitting the query. I'd suggest looking for existing CVEs in the type of bug that your query is supposed to find, verify that the query does indeed find it and then include those existing CVEs in the submission as a proof.

[jorgectf]

Hi @m-y-mo, apologies for the delay. This issues have been assigned CVE-2021-44556 and CVE-2021-44557 :)

[jorgectf]

Just found out the query finds all the results from this cve search. 🎉

[ghsecuritylab]

Your submission is now in status Final decision.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

[ghsecuritylab]

Your submission is now in status Pay.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed