[Python]: Configuration Injection modeling

[Sim4n6]

Query PR

https://github.com/github/codeql/pull/13640

Language

Python

CVE(s) ID list

• CVE-2023-35932

CWE

CWE-074

Report

1. What is the vulnerability? Arbitrary Configuration Injection: Not correctly sanitizing user input before using it to set configuration values into the user's configuration file can lead to arbitrary configuration injection. Under some circumstances, this may result in arbitrary code execution. Directly writing user input coming from an HTTP request parameter or straight from the command-line input into the user's configuration file, without properly sanitizing the input first, would lead to arbitrary configuration injection vulnerability. This, in turn, may permit to achieve of arbitrary code execution, via configuration values that specify executables, such as core.pager, core.editor, and so on.

2. How does the vulnerability work?

   • If a user input value can reach the configuration file either from a remote flow source or from the CLI., it may contain a \r that would get slipped into the configuration file. It would lead to the injection of a key and a value, like this: aaaa\rk1 = v1.

3. What strategy do you use in your query to find the vulnerability?

   • Source: CLI user input or remote flow sources.
   • Sink: either the usual method set() or not common add_section() to the configuration file.
   • Sanitizer: the \r is replaced or deleted within the section, the option or the value.

4. How have you reduced the number of false positives ?

   • It is a very specific one. I believe there is one case where I have got a false positive. Where the value injected went through os.path.dirname(). I don't know if I add it as a sanitizer or not.

5. other information?

   • Sanitizers could be a bit tricky to write, for instance, in Git Arbitrary Configuration Injection (CVE-2023-29007) the injection was NOT due a carriage return \r.

Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).

• [X] Yes
• [ ] No

Blog post link

https://sim4n6.beehiiv.com

[ghsecuritylab]

Your submission is now in status Test run.

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

[xcorail]

Hi @Sim4n6,

Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the findings and the query we have determined this query is too much of an edge case to be included into the CodeQL query suites. We don't deny that the vulnerabilities this query tries to cover can occur in reality. However, the use of local flow sources as this query currently does makes only limited sense for a more general application as part of a query suite. If an attacker is able to exploit such a vulnerability with a local flow source (e.g. by passing in values on the command line), it seems likely that they are already operating from an elevated position. As confirmed by our tests of your query at scale, it's unlikely that the query could yield interesting results when only using remote flow sources. Therefore it's not eligible for a reward under the Bug Bounty program, as our goal is to scale vulnerablity detection.

Best regards and happy hacking!

[ghsecuritylab]

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

[Sim4n6]

No problem @xcorail.

By the way, it caught something interesting... a medium-severity vulnerability that can be exploited in CI/CD env from a CLI input source. It will be published by October. I will let you know the outcome for sure.

[Sim4n6]

@xcorail you were right, RFS is the appropriate impactful source. I've got this unusual hit but the final verdict is informative.