当前位置：文江博客话题详情

整数溢出是如何被利用的？

发布于 2024-09-02 21:27:00 字数 89 浏览 6 评论 0原文

有人对如何利用整数有详细的解释吗？我已经阅读了很多有关这个概念的内容，并且我了解它是什么，并且我了解缓冲区溢出，但我不明白如何通过使整数大于它定义的内存......

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

执笔绘流年 2024-09-09 21:27:00

它绝对是可以利用的，但当然取决于具体情况。

旧版本的 ssh 存在整数溢出问题，可以被远程利用。该漏洞导致 ssh 守护进程创建一个大小为零的哈希表，并在尝试在内存中存储某些值时覆盖内存。

有关 ssh 整数溢出的更多详细信息：http://www.kb.cert.org/ vuls/id/945216

有关整数溢出的更多详细信息：http:// /projects.webappsec.org/w/page/13246946/Integer%20Overflows

回复收藏 0 原文

魂牵梦绕锁你心扉 2024-09-09 21:27:00

我在 60 年代末在 IBM 360/40 上使用了 APL/370。 APL 是一种语言，其中本质上所有事物都是多维数组，并且有令人惊奇的运算符用于操作数组，包括从 N 维到 M 维的重塑等。

毫不奇怪，N 维数组的索引范围为 1..k，其中每个轴都有不同的正 k。并且 k 合法地始终小于 2^31（32 位有符号机器字中的正值）。现在，N 维数组在内存中分配了一个位置。 APL 将根据数组上限检查尝试使用对于轴来说太大的索引来访问数组槽。当然，这适用于 N 维数组，其中 N == 1。APL

不会检查您是否使用 RHO（数组重塑）运算符做了一些极其愚蠢的事情。 APL 最多只允许 64 个维度。因此，您可以创建一个 1-64 维的数组，如果数组维度都小于 2^31，APL 就会执行此操作。或者，您可以尝试创建一个 65 维度的数组。在这种情况下，APL 出错了，令人惊讶地返回了一个 64 维数组，但未能检查轴大小。
（这实际上是“发生整数溢出”的地方）。这意味着您可以创建一个轴大小为 2^31 或更大的数组...但被解释为有符号整数，它们被视为负数。

应用于此类数组的正确 RHO 运算符咒语可以将维度减少到 1，上限为“-1”。将此矩阵称为“虫洞”（稍后您就会明白为什么）。这样的虫洞阵列有
内存中的一个位置，就像任何其他数组一样。但是所有数组访问都会根据上限进行检查...但数组边界检查结果是通过 APL 的无符号比较来完成的。因此，您可以毫无异议地访问 WORMHOLE[1]、WORMHOLE[2]、... WORMHOLE[2^32-2]。实际上，您可以访问整个机器的内存。

APL 还有一个数组赋值操作，您可以在其中填充一个值。
WORMHOLE[]<-0 因此将所有内存清零。

我只这样做了一次，因为它删除了包含我的 APL 工作区、APL 解释器的内存，并且显然是 APL 启用分时功能的关键部分（在那些日子里，它没有受到用户保护）......终端机房
从机械噪音非常大的正常状态（我们有 2741 个 Selectric APL 终端）到完全安静只用了大约 2 秒。
透过计算机室的玻璃，我可以看到操作员抬头惊讶地看着 370 上的灯，因为它们全部熄灭了。随之而来的是大量的奔波。

虽然当时觉得很搞笑，但我还是闭嘴了。

只要小心一点，人们显然可以以任意方式篡改操作系统。

I used APL/370 in the late 60s on an IBM 360/40. APL is language in which essentially everything thing is a multidimensional array, and there are amazing operators for manipulating arrays, including reshaping from N dimensions to M dimensions, etc.

Unsurprisingly, an array of N dimensions had index bounds of 1..k with a different positive k for each axis.. and k was legally always less than 2^31 (positive values in a 32 bit signed machine word). Now, an array of N dimensions has an location assigned in memory. Attempts to access an array slot using an index too large for an axis is checked against the array upper bound by APL. And of course this applied for an array of N dimensions where N == 1.

APL didn't check if you did something incredibly stupid with RHO (array reshape) operator. APL only allowed a maximum of 64 dimensions. So, you could make an array of 1-64 dimension, and APL would do it if the array dimensions were all less than 2^31. Or, you could try to make an array of 65 dimensions. In this case, APL goofed, and surprisingly gave back a 64 dimension array, but failed to check the axis sizes.
(This is in effect where the "integer overflow occurred"). This meant you could create an array with axis sizes of 2^31 or more... but being interpreted as signed integers, they were treated as negative numbers.

The right RHO operator incantation applied to such an array to could reduce the dimensionaly to 1, with an an upper bound of, get this, "-1". Call this matrix a "wormhole" (you'll see why in moment). Such an wormhole array has
a place in memory, just like any other array. But all array accesses are checked against the upper bound... but the array bound check turned out to be done by an unsigned compare by APL. So, you can access WORMHOLE[1], WORMHOLE[2], ... WORMHOLE[2^32-2] without objection. In effect, you can access the entire machine's memory.

APL also had an array assignment operation, in which you could fill an array with a value.
WORMHOLE[]<-0 thus zeroed all of memory.

I only did this once, as it erased the memory containing my APL workspace, the APL interpreter, and obvious the critical part of APL that enabled timesharing (in those days it wasn't protected from users)... the terminal room
went from its normal state of mechanically very noisy (we had 2741 Selectric APL terminals) to dead silent in about 2 seconds.
Through the glass into the computer room I could see the operator look up startled at the lights on the 370 as they all went out. Lots of runnning around ensued.

While it was funny at the time, I kept my mouth shut.

With some care, one could obviously have tampered with the OS in arbitrary ways.

回复收藏 0 原文

谈场末日恋爱 2024-09-09 21:27:00

这取决于变量的使用方式。如果您从不根据与输入整数相加的整数做出任何安全决策（对手可能会引发溢出），那么我无法想象您会如何遇到麻烦（但这种事情可能很微妙）。

话又说回来，我见过很多这样的代码，它们不验证用户输入（尽管这个例子是人为的）：

int pricePerWidgetInCents = 3199;
int numberOfWidgetsToBuy = int.Parse(/* some user input string */);
int totalCostOfWidgetsSoldInCents = pricePerWidgetInCents * numberOfWidgetsToBuy; // KA-BOOM!

// potentially much later
int orderSubtotal = whatever + totalCostOfWidgetInCents;

一切都很好，直到有一天你以 - 21,474,817.95 美元的价格出售 671,299 个小部件。老板可能会生气。

It depends on how the variable is used. If you never make any security decisions based on integers you have added with input integers (where an adversary could provoke an overflow), then I can't think of how you would get in trouble (but this kind of stuff can be subtle).

Then again, I have seen plenty of code like this that doesn't validate user input (although this example is contrived):

int pricePerWidgetInCents = 3199;
int numberOfWidgetsToBuy = int.Parse(/* some user input string */);
int totalCostOfWidgetsSoldInCents = pricePerWidgetInCents * numberOfWidgetsToBuy; // KA-BOOM!

// potentially much later
int orderSubtotal = whatever + totalCostOfWidgetInCents;

Everything is hunky-dory until the day you sell 671,299 widgets for -$21,474,817.95. Boss might be upset.

回复收藏 0 原文

叹沉浮 2024-09-09 21:27:00

常见的情况是代码通过询问将提供的输入数量，然后尝试强制执行该限制来防止缓冲区溢出。考虑一种情况，我声称提供 2^30+10 个整数。接收系统分配4*(2^30+10)=40字节(!)的缓冲区。由于内存分配成功，我可以继续。当我发送第 11 个输入时，输入缓冲区检查不会阻止我，因为 11 < 2^30+10。但我会溢出实际分配的缓冲区。

回复收藏 0 原文