问题标签 [heartbleed-bug]

鉴于最近的心血和更新 openSSL 版本的要求，我已按照所有说明进行操作。

我跑了

然而，每次我运行版本 -a 时，它都不会将构建日期更新为April 7。

为什么是这样。我可以运行哪些命令将 OPENSSL 升级到 1.0.1g 或最新版本？我使用的是 Rackspace Ubuntu 服务器。

我读到了 heartbleed 漏洞，这是 memcpy 的错误。

对 memcpy 的正确调用可能如下所示

但是为什么第三个参数，什么时候会和 src 的大小不同呢？我看过其他示例，其中使用的是 dest 大小，应该什么时候完成？

I came across this Python script that tests the server for the HeartBleed vulnerability:

Would someone be able to explain the content of the "hello", what is being sent and how was this content constructed?

I am not trying to use this script maliciously. I was asked to test a Tomcat 7.0.2 server for the vulnerability: I verified that tcnative-1.dll does use openssl 1.0.1d, but a few of the standalone test tools that I tried testing the server with report that it is not vulnerable.

在得知使用 -DOPENSSL_NO_HEARTBEATS 重新编译将禁用 OpenSSL 1.0.1e 中的 TLSv1 Heartbeats 后不久，我想知道为什么它不是运行时选项，而是可能称为​​ SSL_OP_NO_TLS_HEARTBEATS。

因此，我查看了 SSL.H 并发现“选项”是一个无符号长位掩码，取决于编译平台/模式，它可能是 32 位或 64 位，但似乎 OpenSSL 代码假定为 32 位，而且 - 更重要的是- 这意味着它只有 32 个可能的选项，似乎已经用尽了，除了位 0x00000400L，我从 SSL.H 复制了它们：

您认为这就是他们决定使用 -DOPENSSL_NO_HEARTBEATS 而不是 SSL_OP_NO_TLS_HEARTBEATS 的原因吗？如果是这样，他们为什么不将 0x00000400L 用于 SSL_OP_NO_TLS_HEARTBEATS ？我想知道你对此的看法。实际上，无论这次调查的结果如何，OpenSSL 似乎都需要修复他们的选项系统，因为它似乎已经筋疲力尽了。请让我知道我是否也在那里。

假设，我在 Docker.io 容器中有一个易受攻击的 OpenSSL 服务器。Docker 是否会阻止读取主机的内存？

我的假设是，确实如此。因为漏洞在 OpenSSL 而不是在内核中，所以 Docker 应该隔离容器中的根访问。但是维基百科只说“部分根权限隔离”并暗示它依赖于后端。因此，请指定您是否使用 libcontainer 或 lxc 或其他方式回答。

In light of the recent heartbleed flaw, I am trying to do some analysis of various systems that I connect with (email, login pages, etc). I am trying to use the OpenSSL commandline tool to verify what protocols the systems I connect with are using.

Part of the response is:

Is that all I need to verify that this service is not using Openssl (particularly the buggy 1.0.1 versions)? (I am thinking that it ISN'T enough, as I connected with a server that I KNOW is using Openssl 0.9.8 and it responded with the same string as shown above.)

我们在我们的应用程序中使用 CryptoJS。由于 CryptoJS 使用 OpenSSL，我们是否容易受到 Heartbleed 漏洞的影响？如果是，我们可以做些什么来预防它？

我已阅读http://heartbleed.com/并进行了广泛搜索，但我无法理解这一基本点。

例如，维基百科显示攻击者向易受攻击的服务器发送虚假心跳请求并获得一堆私人数据作为回复，包括 SSL 密钥等： https ://en.wikipedia.org/wiki/Heartbleed

但是，我的问题是：这个攻击者可以是任何人吗？或者攻击者是否已经需要访问服务器上的帐户？

我很惊讶我无法找到此信息，因为在我看来，答案有助于阐明该漏洞对给定服务器的重要性。

例如：如果您有一个小型“私人”服务器，其帐户仅提供给遵循良好安全实践的受信任的人，并且您有理由确定这些帐户没有受到损害，这是否意味着您（最有可能）是明确的？或者攻击者有什么方法可以在不窃取登录信息的情况下获取数据？

在我们的 Ubuntu 12.04 服务器上更新和升级 heartbleed 错误后，我遇到了仅在我们的 Magento 托管站点的登录页面上显示的 MySQL 错误：

在开始之前，我们备份了所有内容。然后我执行了以下命令：

根据https://filippo.io/Heartbleed/，openssl 已成功修补。现在所有 Magento 1.8 站点都因相同的错误（上图）而损坏，但 Joomla 站点似乎不受影响。所有站点都使用 MySQL 5.5.35。

要查看是否是依赖版本问题，我还尝试了以下命令，但没有任何变化：

我还清除了 Magento 缓存和会话文件夹。

在我们第一次关于安全性的 CS 讲座中，我们讨论了 C 的问题，即不检查所谓的缓冲区长度以及可以利用此漏洞的不同方式的一些示例。

在这种情况下，它看起来像是恶意读取操作的情况，应用程序只是读取了许多字节的内存

1. 我断言 Heartbleed 错误是 C 缓冲区长度检查问题的表现是否正确？

2. 为什么恶意使用在尝试读取另一个应用程序的内存时没有导致分段错误？

3. 在写入内存（然后从内存读取）之前简单地将内存归零会导致分段错误吗？或者这在操作系统之间会有所不同吗？还是在其他一些环境因素之间？

4. 显然无法识别对该错误的利用。那是因为心跳函数在调用时没有记录吗？否则肯定任何对 ~64k 字符串的请求都可能是恶意的？