but it's not a vulnerability in the traditional sense. No information gets leaked, no invalid memory is accessed. It's just slow. If being slow is a vulnerability, all python code is a vulnerability.
This is a bad take. The operation is not slow as in "takes longer", but as in "effectively never finishes". (that's what taking minutes on a single request means) That makes it trivial to DoS a service if you know it's running on a standard python runtime. And availability related to untrusted input is very much a vulnerability in a traditional sense.
They set the limit at (on my computer) 0.1ms. Also, their implementation is roughly 100x slower than it should be. Should python also error out on loops that run for more than 1000 iterations? The problem isn't that int parsing is broken, the problem is that web-servers aren't validating their inputs.
It's different layers. You're in control of the loops, so no. (guess what though - recursion level is limited) You're not in control of the int() implementation, so that falls on python.
It's similar to what we've done with hash collisions - we can't count on everyone fixing that in every place released so far, so all languages added hash randomisation at startup. That one fortunately had no side effects like this one does.
> They set the limit at (on my computer) 0.1ms.
That seems reasonable to me. I'm not sure if you're saying it's too low or too high?
> the problem is that web-servers aren't validating their inputs.
And they won't. This would be repeated many times in various form affecting Web servers, job queues, parsers, etc. and keep coming back for decades. We already have that with Java XML entities. They weren't fixed at the source and we get a new implementation with that bug ever day.
What do you mean by "all inputs"? Did you write your whole server from scratch? Did you verify the length of every single int that comes in your query? Fragment? Json? Header? Header part that may be parsed internally by python's standard libs? Chunk lengths? IP conversions? Every external library call? Variables that may turn numeric in future revisions? If that's true, how sure are you you haven't missed a single spot?
> like we have been doing for thirty years in web apps.
I have bad news for you. If everything you said is true, you've been working on some ideal code in a prefect team with no dependencies... But more likely you're going to have a bad collision with reality one day.
