問題タブ [heartbleed-bug]

heartbleed エクスプロイトについて読みましたが、これは memcpy の間違いでした。

memcpy の適切な呼び出しは次のようになります。

しかし、なぜ 3 番目のパラメーターが src のサイズと異なるのでしょうか? dest サイズが使用されている他の例を見てきましたが、いつそれを行う必要がありますか?

Docker.io コンテナに脆弱な OpenSSL サーバーがあるとします。Docker はホストからのメモリの読み取りを防止しますか?

私の仮定は、そうです。バグはカーネルではなく OpenSSL にあるため、Docker はコンテナーでルート アクセスを分離する必要があります。しかし、ウィキペディアは「部分的なルート権限の分離」としか言っておらず、バックエンドに依存していることを示唆しています。したがって、libcontainer または lxc などを使用して回答するかどうかを指定してください。

最近のハートブリードの欠陥に照らして、接続しているさまざまなシステム (電子メール、ログイン ページなど) の分析を試みています。OpenSSL コマンドライン ツールを使用して、接続しているシステムが使用しているプロトコルを確認しようとしています。

応答の一部は次のとおりです。

このサービスが Openssl (特にバグのある 1.0.1 バージョン) を使用していないことを確認する必要があるのはそれだけですか? (Openssl 0.9.8 を使用していることがわかっているサーバーに接続したところ、上記と同じ文字列で応答したため、十分ではないと考えています。)

アプリケーションでCryptoJSを使用しています。CryptoJS は OpenSSL を使用しているため、Heartbleed バグに対して脆弱ですか? はいの場合、それを防ぐために何ができますか?

Ubuntu 12.04 サーバーでハートブリード バグを更新およびアップグレードした後、Magento がホストするサイトのランディング ページのみに表示される MySQL エラーに遭遇しました。

始める前に、すべてをバックアップしました。次に、次のコマンドを実行しました。

https://filippo.io/Heartbleed/によると、openssl は正常にパッチされました。現在、すべての Magento 1.8 サイトが同じエラー (上記) で壊れていますが、Joomla サイトは影響を受けていないようです。すべてのサイトで MySQL 5.5.35 を使用しています。

依存バージョンの問題かどうかを確認するために、次のコマンドも試しましたが、変化はありませんでした。

Magento のキャッシュとセッション フォルダーもクリアしました。

セキュリティに関する最初の CS レクチャーの 1 つで、疑惑のバッファ長をチェックしないという C の問題と、この脆弱性が悪用されるさまざまな方法の例について説明しました。

この場合、悪意のある読み取り操作のケースのように見えます。アプリケーションがメモリのバイト数を読み取っただけです。

1. Heartbleed バグは C バッファの長さチェックの問題の現れであると主張するのは正しいですか?

2. 別のアプリケーションのメモリを読み取ろうとしたときに、悪意のある使用によってセグメンテーション違反が発生しなかったのはなぜですか?

3. メモリに書き込む前にメモリをゼロにするだけで（その後メモリから読み取ると）、セグメンテーション違反が発生しますか？または、これはオペレーティング システムによって異なりますか? それとも、他の環境要因の間ですか？

4. どうやらバグの悪用は特定できません。これは、呼び出されたときにハートビート関数がログに記録されないためですか? そうでなければ、〜64k文字列に対するリクエストは悪意がある可能性が高いですか?