Heartbleedを使用して他のプロセスからメモリを取得できますか？
http://heartbleed.com/ によると、メモリの内容がサーバーからクライアントに、またはその逆にリークされる可能性があります。
別のブラウザープロファイルで（ただし、同じユーザーの下で）バンキングしていたとしましょう。別のブラウザープロファイルがたまたまHeartbleed攻撃の標的となった場合、これは私の銀行取引セッションが侵害された可能性があることを意味しますか？ Linux、Windows、または他の何かが使用されているかどうかは重要ですか？
よく書かれた分析が http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html にあり、コードサンプルが揃っています。
著者 Sean Cassidy は次のように述べています（私の強調）：
リクエスタが実際にペイロードバイトを提供しなかった場合、彼女がそうしたとしたらどうでしょうか。 plが本当に1バイトだけの場合はどうなりますか？次に、memcpyからの読み取りは、SSLv3レコードの近くにあったメモリを読み取ります。
そして、どうやら、近くにはたくさんのものがあります。
正直なところ、Heartbleedの脆弱性を見つけた人々の主張に少し驚いています。それを聞いたとき、私は64KBでは秘密鍵のようなものを探すには不十分であると考えました。少なくともx86ではヒープが大きくなるので、plは単にbpなどの新しく割り当てられたメモリに読み取るだけであると考えました。キーなどは以前に割り当てられているため、読み取ることができません。もちろん、最新のmalloc実装では、これが常に正しいとは限りません。
さらに、他のプロセスのメモリを読み取ることができないため、これらの「ビジネスクリティカルドキュメント」はプロセスのメモリ内にあり、64KB未満である必要があります。近くのpl。
代替の視点Erik Cabetas の Include Security から、Redditにコメント：
このバグについて私の友人といくつかの議論をしていた。彼は、ヒープ全体のさまざまな特定サイズの割り当てを使用して、ヒープフラグメントのすべての64kチャンクを読み取ることで、OPのリンクのSeanが示唆する線形的な方法ではなく、これを悪用できると考えています。 ptmalloc/linuxが割り当てる方法について考えた後、これは確かに可能だと思います。 codenomicronの.fi担当者は鋭い人です。ラボ環境で割り当てを適切に取得できたに違いありません。
編集：ショーンは 更新済み ：
そして、どうやら、近くにはたくさんのものがあります。
Mallocを使用してメモリを動的に割り当てる方法には（少なくともLinuxでは）、sbrkを使用する方法とmmapを使用する方法の2つがあります。メモリがsbrkで割り当てられている場合、それは古いheap-grows-upルールを使用し、これで見つけることができるものを制限しますが、複数の要求（特に同時に）はまだ楽しいものを見つけることができます。
ただし、mmapを使用すると、すべてのベットがオフになります。使用されていないメモリはmmapに割り当てることができます。これは、ハートブリードに対するほとんどの攻撃が対象とするものです。
そして最良の部分：要求されたブロックが大きいほど、sbrkではなくmmapによって提供されるリクリーが多くなります。
@ scuzzy-deltaの答えを追加するには、定義により、アプリケーションコードのバッファオーバーランはアプリケーションコードにのみ影響します。オペレーティングシステムは、さまざまなプロセス間の分離を維持し、プロセスが別のプロセスのメモリ空間にアクセスすることを許可しません。
バッファオーバーランが「書き込み」説得である場合（攻撃者がターゲットをバッファの終わりを超えてwriteバイトに強制する）場合、これは攻撃者が標的のアプリケーションを制御し、入札を行わせる敵対的なハイジャックに変わりました。アプリケーションレベルの権限は、ブラウザのすべてのプロファイルの読み取り（画面のコンテンツやキーボードエントリの取得など）（ブラウザの「クライアント」側で発生した場合など）など、かなりのいたずらを実行するのに十分です。 ）。ただし、この場合、「ハートブリード」の脆弱性は「読み取り」オーバーランであり、データを公開しますが、ターゲットシステムには影響しません。これにより、敵意のあるハイジャックの直接的なリスクとその悲惨な結果が排除されます。
ただし...
ターゲットプロセスのアプリケーションメモリからシークレットを取得すると、より広範な攻撃に利用される可能性があります。たとえば、ターゲットがWebサーバーである場合、ハートブリードの問題により、他のユーザーの名前とパスワードが（適切な運で）明らかになり、これらのユーザーとしてこれらのユーザーとしてログオンするために使用できます。これは問題になる可能性があります。
Webブラウザーの場合、つまりクライアント側では、someブラウザーは、メモリの断片化の問題を回避するために、個別のプロセスインスタンスを起動する習慣があることに注意してください。長時間実行されるセッションでは、Flashプラグインがクラッシュしたときにブラウザ全体が失われるのを防ぐためにも。ただし、すべてのブラウザーがこれを行うわけではありません。また、そうする人にとってさえ、体系的には行いません。タブを1つのプロセスに「まとめて」グループ化するために、ヒューリスティックに従います。
余分なポイントは、これらのプロセスがしばしばいくつかの共有メモリを使用して、必要な情報、特にパスワードとCookieキャッシュ、およびSSLセッションを交換することです。正確には、攻撃者が取得したい種類のジューシーなデータ。
明るい面では、クライアントを攻撃するには、クライアントが通信するserverが攻撃を実行する必要があります。攻撃者が開始することはできません。クライアントの接続を待つ必要があります。