# Int/str conversions broken in latest Python bugfix releases

**URL:** <https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889>\
**Category:** Core Development\
**Created:** [September 8, 2022, 10:40pm UTC](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889 "2022-09-08T22:40:32Z")\
**Posts on this page:** 1\
**Showing post:** 41

<div class="post-metadata">

**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\
**Post date:** [September 12, 2022, 10:02am UTC](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889/41 "2022-09-12T10:02:06Z")

</div>

Thanks @oscarbenjamin for raising this issue on Discuss.

> [@](#):
>
> This CVE is owned by the RedHat CNA … There is no _good_ way to do a security release with every little thing happening at the same time across multiple global organizations many of whom are volunteers.

RedHat is a global company valued at USD $34 billion (with a B) when IBM purchased them three years ago. Let’s not blame overworked volunteers here.

If this were a high priority, or even a medium priority, for RedHat, the CVE details would have been populated less tardily.

This vulnerability is in a class of attack that has public knowledge for over a decade: pass a huge chunk of data to the application and try to DOS it or overflow a buffer. The specific vulnerability (quadratic behaviour of str ↔ int conversions) has been public for at least four years. RedHat reserved the CVE 30 months ago, and the Python security team has known about it for two years.

- Similar [XML DOS attacks](https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/november/xml-denial-of-service-attacks-and-defenses) have been known before 2009, although I’m not sure whether specific str ↔ int conversion attacks would work.
- A four year old [Scala example](https://security.snyk.io/vuln/SNYK-JAVA-ORGJSON4S-72740).
- A [four year old whitepaper](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2018/jackson_deserialization.pdf) on the issue.
- [Discussion on Reddit](https://www.reddit.com/r/java/comments/9jyv58/lowbandwidth_dos_vulnerability_in_jacksons/).
- [A Haskell example made public a year ago](https://cs-syd.eu/posts/2021-09-11-json-vulnerability).

I don’t buy the need to push out a fix to this without public discussion. This class of vulnerability was already public, and has been for years.

Even if it turns out that the chosen solution is the best, or only, solution, the secrecy and “trust us, we know best” from the security team was IMO not justified.

I feel that string hashing attacks are much more serious. Applications can, if they choose, perform length checks on data much more easily than they can recognise hash collisions. And yet we discussed [hash randomization publicly](https://mail.python.org/pipermail/python-dev/2011-December/115116.html) in 2011 and 2012 before pushing it out. If we could discuss that publicly, why couldn’t we discuss this?

It seems that the threat here was in no way severe and urgent enough to justify the lack of community discussion.

---

_[View the full topic](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889)._