python
Unbounded Resource Exhaustion Vulnerability in `Tools/freeze/checkextensions.py`
Bug Description: The code will re-scan the newly generated content after replacing the variable. If a variable is defined to contain itself (i.e., a recursive definition), this process will fall into infinite recursion.
This recursion can lead to two forms of attacks: one is to cause an infinite loop and deplete CPU resources, and the other is to cause the string to grow infinitely and deplete memory resources. The final result will all lead to the application crashing or being unresponsive.
Vulnerability Locations : 1.https://github.com/python/cpython/blob/e64395e8eb8d3a9e35e3e534e87d427ff27ab0a5/Tools/freeze/checkextensions.py#L72
Repair Status: None
Common Information:
- CPython Version: main branch
- Operating System: Linux
- Credits: Finder is kexinoh (Xiangfan Wu) from QI-ANXIN Technology Research Institute.
Linked PRs
- gh-136093
Ok, it actually affects freeze.py so I think we can backport it until 3.9. However, I haven't checked if this is a realistic attack
Out of curiosity, is freeze.py still maintained? The last update was 2 years ago and for this specific file 16.
Is it really a security issue? Tools/freeze is an internal tool, which is used when CPython is built. If someone can affect the building process - you have much bigger problems.
I still think that this should be fixed, just doubting that this is a security issue.
Although it's internal, it's still somehow documented: https://docs.python.org/3/faq/programming.html#how-can-i-create-a-stand-alone-binary-from-a-python-script. But I agree that it can be hard to exploit. I'm more worried about "mistakes" that can lead to issues.
Hmm, is triggering this even possible in practice? From what I understand this would require having a cyclic variable definition in a Setup file, but Make already detects variable cycles, so wouldn't building the module fail before this could be a problem? E.g. adding CC=$(CC) will cause Make to exit with *** Recursive variable 'CC' references itself (eventually). Stop..
I'm not quite clear about the specific construction process of make, but what I want to explain is that for
a=$aa
This situation can also cause problems, but there is no actual variable loop.
Thank you for opening an issue @kexinoh. I wrote the patch yesterday, but needed an issue number for reference.
I agree that this is a minor bug, and perhaps not exploitable. But it is worth to fix it. Unfortunately, there are no unit tests for all this code, so I cannot add new tests for this function. I tested it manually.
