ValueError:超过整数字符串转换的限制(4300)


>>> import sys
>>> sys.set_int_max_str_digits(4300)  # Illustrative, this is the default.
>>> _ = int('2' * 5432)
Traceback (most recent call last):
...
ValueError: Exceeds the limit (4300) for integer string conversion: value has 5432 digits.

Python 3.10.7为类型转换引入了这一突破性的更改。

文档:整数字符串转换长度限制

事实上,我不明白为什么

  1. 这是介绍和
  2. 4300的默认值是从哪里来的?听起来像是一个任意的数字

如果您收到此错误:

ValueError: Exceeds the limit (4300) for integer string conversion

您可以通过以下方式提高限额:

import sys
sys.set_int_max_str_digits(0)

现在,您可以进行更大的计算。

文档链接:

https://docs.python.org/3/library/stdtypes.html#integer-字符串转换长度限制

请参阅github问题CVE-2020-10735:通过大型int防止DoS&lt->str转换#95778:

问题

CPython中发现拒绝服务(DoS)问题因为我们在int实现中使用二进制bignum。一个巨大的在转换为基数为10(十进制)的大数字字符串或从中转换位数。没有有效的算法可以做到这一点。

对于实现网络协议和对输入执行int(unsested_string_or_bytes_value)的数据序列化在不限制输入长度或做log("processing thing id %s", unknowingly_huge_integer)或任何类似的概念,将int转换为字符串而无需首先检查其大小。(httpjsonxmlrpclogging,将大值加载到整数通过线性时间转换,例如存储在yaml或任何基于用户控制计算更大值的东西输入……然后尝试稍后以十进制形式输出)。所有这些都可能在不受信任的情况下遭受消耗CPU的DoS数据

每个人都为此审核所有现有代码,添加长度保护,在任何地方都坚持这种做法是不可行的,也不是我们认为绝大多数用户都想做什么。

此问题已报告给Python安全响应小组自2020年初以来,一些不同的人多次最近几周前,当我正在打磨PR,因此它将在3.11.0rc2之前准备好。

缓解

在与Python安全响应小组讨论后邮件列表的结论是,我们需要限制用于非线性时间转换的整数到字符串转换(任何不是2次幂基数的东西)。并提供配置或禁用此限制。

Python指导委员会意识到了这一变化,并将其视为必需的

可以在Python核心开发人员讨论最新Python错误修复版本中中断的线程Int/str转换上找到进一步的讨论。

我发现Steve Dower的这条评论很有启发性:

我们对流程缺乏透明度表示歉意。这个该问题首先报告给了其他一些安全团队在Python安全响应小组中,我们一致认为正确的解决方案是修改运行时。

报告和修复之间的延迟完全是我们的错。安全性团队由志愿者组成,我们的可用性并不总是可靠的,没有人"负责"协调工作。我们一直讨论如何改进我们的流程。然而,我们确实同意剥削的可能性很高,我们不想在没有可用和可供使用的修复程序的情况下披露该问题。

我们确实采取了一些替代方法他们中的许多人。执行int(gigabyte_long_untrusted_string)的代码可以位于json.load或HTTP头解析器内的任何位置,并且可以运行深的解析库无处不在,并且倾向于使用int不加区别地(尽管它们通常已经处理ValueError)。期望每个库向每个int()调用添加一个新参数会导致成千上万的漏洞被归档并制造用户不可能相信他们的系统拒绝服务。

我们同意这是一个沉重的打击在核心,但这也是唯一有机会给用户留下信心的锤子在应用程序的边界运行Python。

现在,我个人倾向于同意int->str转换应该做一些其他的事情,而不是提高。我被否决了,因为它会坏掉往返,这是一个合理的论点,我接受了。我们可以随着时间的推移,仍然会改进这一点,并使其更加可用。然而,在大多数情况下在我们看到的情况下,渲染过长的字符串是不可取的任何一个这应该是选择加入的行为。

从str中引发异常可能太多,而且可能重新考虑,但我们看不到向int的每个用户,所以这肯定会保持全局性。

最新更新