Skip to content

[Python]: CWE-611: XXE #424

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
jorgectf opened this issue Aug 25, 2021 · 15 comments
Closed
1 task done

[Python]: CWE-611: XXE #424

jorgectf opened this issue Aug 25, 2021 · 15 comments
Labels
All For One Submissions to the All for One, One for All bounty

Comments

@jorgectf
Copy link
Contributor

jorgectf commented Aug 25, 2021

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:

Already existing:

@jorgectf jorgectf added the All For One Submissions to the All for One, One for All bounty label Aug 25, 2021
@ghsecuritylab
Copy link
Collaborator

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
Copy link
Contributor

m-y-mo commented Sep 9, 2021

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
Copy link
Collaborator

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
Copy link
Contributor Author

jorgectf commented Oct 16, 2021

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

@jorgectf
Copy link
Contributor Author

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
Copy link
Contributor

m-y-mo commented Nov 23, 2021

@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
Copy link
Collaborator

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
Copy link
Contributor Author

@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
Copy link
Contributor

m-y-mo commented Nov 23, 2021

@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
Copy link
Contributor Author

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

@jorgectf
Copy link
Contributor Author

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

@ghsecuritylab
Copy link
Collaborator

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
Copy link
Collaborator

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

@xcorail
Copy link
Contributor

xcorail commented Mar 15, 2022

Created Hackerone report 1512937 for bounty 376399 : [424] [Python]: CWE-611: XXE

@xcorail xcorail closed this as completed Mar 15, 2022
@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Closed.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
All For One Submissions to the All for One, One for All bounty
Projects
None yet
Development

No branches or pull requests

4 participants