OpenBSDの保護機能はHeartbleedによるダメージを軽減しますか？
OpenBSDは、OSに固有の エクスプロイトに対する実質的な保護のリスト を提供します。これらの機能のほとんどは、他のオペレーティングシステムにはないか、少なくともデフォルトではオンになっていません。上記のOpenBSD Webサイトのリストには、次のものが含まれます。
- strlcpy（）およびstrlcat（）
- メモリ保護浄化
- W ^ X
- .rodataセグメント
- ガードページ
- ランダム化されたmalloc（）
- ランダム化されたmmap（）
- atexit（）およびstdio保護
- 権限分離
- 特権の取り消し
- Chroot監獄
- 新しいuid
- プロポリス
- ... その他
OpenBSDのセキュリティ保護は、Heartbleed攻撃からのデータ露出を軽減しますか？
言い換えれば、OpenSSLを使用するApache/nginx httpsサーバーは、OpenBSDで実行されていたため、Heartbleed攻撃に対する脆弱性が低くなるのでしょうか？
番号。
OpenBSDにはshouldがHeartbleedをクラッシュまたは束全体のリークに変えるべき措置（具体的には、malloc（）ガードページと割り当て解除されたメモリのワイプ）があります。 「0x0d」バイトの。ただし、ブログの投稿 here に記載されているように、OpenSSLは独自のカスタムメモリ管理システムを使用して、これらの対策を打ち破っています。
OpenSSLのメモリ管理がどのように機能するかについて、いくつかの誤解があるようです。
OPENSSL_mallocとOPENSSL_freeは、デフォルトでシステムのmallocとfreeを呼び出すだけです（いくつかの間接参照があるため、アプリケーションは必要に応じてこれらの関数を再定義できますが、OpenSSLはそれを行いません）。ただし、一部のデータ構造（特に入力バッファー）については、以前に割り当てられたが未使用のアイテムをフリーリストに保持しますが、実際には解放しません。使用後にバッファの内容を無害化しないため、バッファがフリーリストから取得されて再利用された場合、以前の内容がまだ存在する可能性があります（システムが解放されていたとしても）。
ただし、他のほとんどの場合、OpenSSLは実際にはシステムのmallocおよびfreeを呼び出しているだけなので、ガードページ（16K入力バッファークラッシュの終わりを超えて読み取りを行っていたはずです）のような緩和策と解放されたメモリのクリア（停止したはずです） OpenSSLの現在のメモリ管理を使用していても、人々が目にした大きなデータ漏えいの一部は役に立ちました。以前の入力バッファーの内容を公開したり、有効な（解放されていない）ヒープの場所にあるプライベートbignumデータを使用したりはしませんでした（ガードページを使用してオーバーリードが発生しないようにする場合を除く）。