問題タブ [heartbleed-bug]

Heartbeat の RFC 6520 を読んだ後、いくつかの質問が残っています。

https://www.rfc-editor.org/rfc/rfc6520

具体的には、ハートビートに任意のペイロードやパディングを含める必要がある理由がわかりません。私が理解していることから、ハートビートの目的は、相手が回線の反対側でまだ注意を払っていることを確認することです。

これらの可変長のカスタム ペイロードが提供するもので、固定の要求と応答では提供されないものは何ですか?

例えば

結局のところ、FTP は NOOP コマンドを使用して接続を維持しますが、これは正常に機能しているようです。

私の理解では、Heartbleed の問題は以前のリクエストのメモリへのアクセスでしたか? 使用後にメモリーを消去することはできませんか？リクエストごとに異なるメモリ空間を使用するには、アクセスできませんか? Web サーバー (apache や nginx など) が複数のプロセスで起動されている場合、それらはユーザー情報を含むメモリを共有していますか?

簡単に言えば、私の質問: より安全なメモリ アクセス モデルを使用するように Apache/Nginx/others を構成することは可能ですか?

Heartbleed 2.0 が最終的に登場するので、パフォーマンスの低下は問題ではありません。その場合は、多くの作業を行う代わりに、ちょっとした笑いを楽しむだけです。

openSSL のハートビートのパディング部分について理解できないことがあります。openssl 1.0.1g のコードでは、次のように表示されます。

パディングの長さが16であることを示していますが、RFC6520では、パディングの長さは少なくとも16バイトであると述べています。クライアントがパディング (32 バイト以上) を含むハートビートを送信した場合、OpenSSL のコードにはまだ脆弱性がありますか?

ハートブリードエクスプロイトでは、基本的にサーバーから多くの奇妙な文字（印刷できない）を取得します。

連続メモリセグメントを読み取るときに、印刷できない文字を解釈する方法を誰か教えてもらえますか?

現在、本番サーバーには PHP 5.5.1 がインストールされており、正常に動作しています。

PHP 5.5.1 (cli) (ビルド: 2014 年 1 月 14 日 11:37:09)

Copyright (c) 1997-2013 PHP グループ

Zend Engine v2.5.0、Copyright (c) 1998-2013 Zend Technologies

ただし、この投稿によると、 PHP は OpenSSL の問題を修正するために 5.5.12 をリリースしました。CodeIgniter で実行しています。

私が見たように、5.5.1 と 5.5.12 の間に重大な変更はなく、バグ修正といくつかの追加のみです。PHPのバージョンアップは順調に進んでいるはずです。

ただし、最近、OpenSSL の新しいバージョンにアップグレードして、ハートブリード バグを回避しました。では、同じ理由で PHP をアップグレードする必要があるのでしょうか?

不足しているものがない場合、アップグレードによってバージョン関連の問題が発生することはありませんか?

注:投稿で共有ホスティング/サーバーの例に言及しているように、ロード バランサーの背後で実行されている独自の複数の専用サーバーがあります。

OpenSSL v 0.9.8 を実行するサーバーと、OpenSSL 1.0.1e に基づくクライアントがあります。クライアントの OpenSSL ライブラリが -DOPENSSL_NO_HEARTBEATS でコンパイルされている場合、サーバーに接続できません。私が見るのはエラーページだけです。何か提案してください。これをデバッグする方法は何ですか?

Java 文字列オブジェクトは不変であり、ガベージ コレクターは非同期であるため、認証情報を文字列に格納すると、スレッド セーフを優先するある種のセキュリティが妨げられます。

このような情報を安全に処理するには、可変性が必要です。つまり、以前は機密情報を格納するために使用されていたメモリをゼロにします。

HeartBleed の脆弱性があるバージョンの openssl を使用している可能性があるとします。

認証の単純な実装により、JVM メモリがユーザー名とパスワードで散らばってしまう可能性があるのではありませんか?

情報が機密ではないことを先験的に知ることができない場合、 java.lang.string を完全に回避する必要がありますか?

副次的な質問として、JVM はリスクを軽減するために何ができるでしょうか? 「回収されたメモリをできるだけ早くゼロフィルする」ようなスイッチについては知りません。

これの目標は、これを ansible または fabric を備えた多くのマシンで実行して、ハートブリードに対して脆弱なマシンを見つけることです。Heartbleed はしばらく前から出ていましたが、これは Ubuntu 12.04 LTS にインストールされているバージョンを検索します。

Ubuntu ユーザーの場合、パッチが適用された正しいバージョンもリリースに依存します。このリストを使用して、リリースの最小の安全なバージョンを確認してください。

私はしばらくこれをいじっていましたが、なぜこれがハイフンを超えて一致しないのかわかりません:

一致します

それ以外の

私が試してみました：

私はおそらく非常に明らかに間違ったことをしています。助けてください。

私の論理は次のとおりです。

1. マシンに最小安全バージョン以上があるかどうかを確認しますか? もし機械なら
2. 安全なバージョン以上で、すべて問題ありません。何もしません。
3. マシンに安全なバージョン以上がない場合、マシンがより低い安全でないバージョンと一致する場合は、別の正規表現検索を実行します。
4. マシンが古い/安全でないバージョンと一致する場合は、何かを行います。

したがって、クライアント マシンには、単一の php アプリケーションを提供する Apache 2.2 がインストールされています。Apache ssl_module が有効になっておらず、https 経由でアプリケーションを提供するためのそれぞれの構成がありません。ポート 443 に関する限り、開いているのか接続を拒否しているのかはわかりませんが、調べることはできます。PHP 側では、インストールされているバージョンに、現在無効になっている脆弱な OpenSSL 拡張機能がパッケージされていることがわかっています。

ここで、php openssl 拡張機能を有効にする必要があります。私のアプリケーションは、安全な接続のみを受け入れる外部 API (特に flickr) に対して https 要求を実行する必要があるためです。たぶん、私はハートブリードの問題全体に少し混乱している（または偏執的である）かもしれませんが、次の質問があります。

1/ 脆弱な php openssl 拡張機能を有効にすると、アプリケーションやサーバーがハートブリード バグに対して脆弱になりますか? そしてどうやって？

2/ Apache ssl_module と openssl php 拡張機能の相関関係 (ある場合) は何ですか? ある前提条件は他の前提条件であり、どのような場合ですか?

前もって感謝します