3 ms·

From the link: > Everyone auditing all existing code for this, adding length guards, and maintaining that practice everywhere is not feasible nor is it what we

by bo1024 4y ago

From the link: > Everyone auditing all existing code for this, adding length guards, and maintaining that practice everywhere is not feasible nor is it what we deem the vast majority of our users want to do. It's hard not to read this as "we want to use untrusted input everywhere with no consequences". Seems like we'll be kicking as many issues under the rug as we're fixing with this change, right?

Dylan16807 4y ago
It's easy for me not to read it that way! Converting to an integer is a very good start for validating many kinds of input.
bostik 4y ago
I read it the other way round - untrusted input is used in various places where doing such inline checks is prohibitively tricky. The examples given are quite telling: json, xmlrpc, logging. First two are everywhere in APIs. The third is just ... everywhere. Are you really going to use a JSON or XML stream parser first before feeding it to the stdlib module? And one that does not try to expand the read values to native types? As for logging, that is certainly the place where you are not only expected, but often required to use untrusted input. The fix feels like a heuristic and a compromise. None of the [easily available] solutions are robust, solid or performant, so someone picked an arbitrary threshold that should never be hit in sane code. The linked issue mentions that GMP remains fast even in face of absurdly big numbers. No surprise, the library is literally designed for it: MP stands for multi-precision (ie. big int and friends).
- adgjlsfhk1 4y ago
  this would all make more sense if python was using a reasonably fast string to int routine, but the one they are using is asymptotically bad, and the limit they chose is roughly a million times lower than it should have been.
rwmj 4y ago
Did they consider doing tainting (like Perl)? Input strings are marked as tainted and anything derived from them, except for some specific operations that untaint strings. If you use a tainted string for a security-sensitive operation then it fails. http://perlmeme.org/howtos/secure_code/taint.html http://perlmeme.org/howtos/secure_code/taint.html
- rPlayer6554 4y ago
  That's very interesting. That link is dead though.
  - shakna 4y ago
    I think the broken link refers to the same information found here [0]. One of the nicest AND most frustrating parts of taint-mode, for myself, is that once activated it remains on until the end of execution. It's not scoped, which removes some of the headache of using such a thing. Switch on, and assume always on. [0] https://perldoc.perl.org/perlsec#Taint-mode https://perldoc.perl.org/perlsec#Taint-mode
    - rwmj 4y ago
      Back when we were writing websites in Perl (cough, 20 years ago), we also had taint mode on everywhere. It was fairly unobtrusive, and likely stopped a few attacks like: http://example.com/upload.pl?file=../../../../etc/passwd http://example.com/upload.pl?file=../../../../etc/passwd The main thing you had to remember was the parameters (all tainted of course) had to be filtered through a regular expression before you could use them.
userbinator 4y ago
It's hard not to read this as "we want to use untrusted input everywhere with no consequences". Seems like we'll be kicking as many issues under the rug as we're fixing with this change, right? It reminds me of this old "feature" PHP had, no doubt everyone who was on the Internet at the time of its popularity saw its unintended effects: https://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc https://www.php.net/manual/en/info.configuration.php#ini.mag...

by bo1024 4y ago

Dylan16807 4y ago

It's easy for me not to read it that way! Converting to an integer is a very good start for validating many kinds of input.

bostik 4y ago

I read it the other way round - untrusted input is used in various places where doing such inline checks is prohibitively tricky. The examples given are quite telling: json, xmlrpc, logging. First two are everywhere in APIs. The third is just ... everywhere. Are you really going to use a JSON or XML stream parser first before feeding it to the stdlib module? And one that does not try to expand the read values to native types? As for logging, that is certainly the place where you are not only expected, but often required to use untrusted input. The fix feels like a heuristic and a compromise. None of the [easily available] solutions are robust, solid or performant, so someone picked an arbitrary threshold that should never be hit in sane code. The linked issue mentions that GMP remains fast even in face of absurdly big numbers. No surprise, the library is literally designed for it: MP stands for multi-precision (ie. big int and friends).

adgjlsfhk1 4y ago
this would all make more sense if python was using a reasonably fast string to int routine, but the one they are using is asymptotically bad, and the limit they chose is roughly a million times lower than it should have been.

rwmj 4y ago

Did they consider doing tainting (like Perl)? Input strings are marked as tainted and anything derived from them, except for some specific operations that untaint strings. If you use a tainted string for a security-sensitive operation then it fails. http://perlmeme.org/howtos/secure_code/taint.html http://perlmeme.org/howtos/secure_code/taint.html

rPlayer6554 4y ago
That's very interesting. That link is dead though.
- shakna 4y ago
  I think the broken link refers to the same information found here [0]. One of the nicest AND most frustrating parts of taint-mode, for myself, is that once activated it remains on until the end of execution. It's not scoped, which removes some of the headache of using such a thing. Switch on, and assume always on. [0] https://perldoc.perl.org/perlsec#Taint-mode https://perldoc.perl.org/perlsec#Taint-mode
  - rwmj 4y ago
    Back when we were writing websites in Perl (cough, 20 years ago), we also had taint mode on everywhere. It was fairly unobtrusive, and likely stopped a few attacks like: http://example.com/upload.pl?file=../../../../etc/passwd http://example.com/upload.pl?file=../../../../etc/passwd The main thing you had to remember was the parameters (all tainted of course) had to be filtered through a regular expression before you could use them.

userbinator 4y ago

It's hard not to read this as "we want to use untrusted input everywhere with no consequences". Seems like we'll be kicking as many issues under the rug as we're fixing with this change, right? It reminds me of this old "feature" PHP had, no doubt everyone who was on the Internet at the time of its popularity saw its unintended effects: https://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc https://www.php.net/manual/en/info.configuration.php#ini.mag...