データサイエンスとデータベース

「ハートブリード」OpenSSLバグの修正：システム管理者向けのチュートリアル

それで、とにかくバグは正確には何ですか？

簡単な概要は次のとおりです。

潜在的に重大な問題広く使用されている OpenSSL 暗号ライブラリ。脆弱性がに存在するため、「ハートブリード」と呼ばれます。「ハートビート拡張」（RFC6520）にトランスポート層セキュリティ（TLS）これはメモリリーク（「ブリード」）の問題です。この脆弱性の影響を受けるサイトでは、ユーザーパスワードやその他の重要なデータが侵害されている可能性があります。

この脆弱性は、次の2つの理由で特に危険です。

重要な可能性のあるデータが漏洩しています。
攻撃は痕跡を残しません。

影響を受ける OpenSSLバージョン 1.0.1から1.0.1f、1.0.2-beta、および1.0.2-beta1です。

誰が問題の影響を受けますか？

簡単な答え：これらのバージョンのOpenSSLを使用するすべての人。

そして、それは多くの企業と多くの人々です。

Heartbleedチュートリアルに入る前に、ここに簡単なサンプルを示します。大手企業やウェブサイト影響を受けていることがわかっており、サイトにパッチを適用する必要があるもの： Gmail 、ヤフーメール、 Intuit TurboTax 、 USAA 、Dropbox、Flickr、Instagram、 Pinterest 、 SoundCloud 、タンブラー、 GitHub 、 GoDaddy 、ボインゴワイヤレス、などなど。

もし、あんたが

Heartbleedの脆弱性を修正するために、あらゆる規模の企業の多くの企業Webサイトにパッチが適用されています（またはパッチを適用する必要があります）。

この脆弱性は2011年12月31日から存在しており、OpenSSLは約インターネットホストの66％。

ユーザーとして、頻繁にアクセスするサイトが影響を受け、データが危険にさらされている可能性があります。開発者としてまたはシステム管理者、担当するサイトまたはサーバーも影響を受けている可能性があります。

では、影響を受けるサイトのいずれかを使用する場合、自分自身を保護するために何をする必要がありますか？

あなたがすべき主なこと すぐに のいずれかのパスワードを変更することです影響を受けるサイトログインアカウントをお持ちの方。

また、OpenSSLを使用するサイトのシステム管理者である場合、Heartbleedを修正して保護するには、何をする必要がありますか？

OpenSSL 1.0.1を使用している場合、 次のいずれかを実行します すぐに ：

OpenSSL 1.0.1g、またはにアップグレードします
-DOPENSSL_NO_HEARTBEATSを使用してOpenSSLを再コンパイルします。

OpenSSL 1.0.2を使用している場合、 脆弱性は1.0.2-beta2で修正されます でもそれを待つことはできません 。暫定的に、次のいずれかを実行します すぐに ：

OpenSSL 1.0.1gに戻す、または
-DOPENSSL_NO_HEARTBEATSを使用してOpenSSLを再コンパイルします。

ほとんどのディストリビューション（Ubuntu、Fedora、Debian、Arch Linuxなど）はすでにパッケージをアップグレードしています。 Gentooのような場合は、パッチを適用したebuildにアップグレードする。

アップグレード（または再コンパイル）してサーバー上に安全なバージョンを確立したら、次のようにします。

影響を受ける可能性のあるすべてのプロセスを必ず再起動してください。このバグの影響を受ける主なデーモンには、Apache、Nginx、OpenVPN、sshdなどがあります。基本的に、libsslに対してリンクされているすべてのもの。（これらのデーモンの再起動で十分であることに注意してください。これらのバイナリはopensslライブラリと動的にリンクされているため、再構築する必要はありません。）
次のようなツールを使用して、脆弱性がなくなったことを確認しますこのオンラインテストまたは GitHubのこのツールまたは Pastebinのこのツール。

インフラストラクチャが脆弱な場合は、実行できる、または実行する必要のあるHeartbleedチュートリアルの手順があります。そのような緩和策の有用なリストが利用可能ですここに。

興味のある人のために、もっとひどいハートブリードの詳細…

で説明されているように修正のためのGitHubコミット、TLSハートビート拡張機能の処理における境界チェックの欠落を悪用して、接続されたクライアントまたはサーバーに最大64kのメモリを公開する可能性があります。

公開されたメモリは潜在的にゴミである可能性がありますが、悪意のある攻撃者にとって非常に価値があることが簡単に判明する可能性があります。

Heartbleedの脆弱性の仕組みは次のとおりです。攻撃者はペイロードとペイロードの長さを提供します。ただし、ペイロードの長さが実際に攻撃者によって提供されたことを確認するための検証は行われません。ペイロードの長さが指定されていない場合、範囲外の読み取りが発生し、ヒープからプロセスメモリがリークします。

以前のリクエストヘッダーのリークは、非常に深刻なセキュリティ問題になる可能性があります。具体的には、以前のユーザーのログイン投稿データは、ユーザー名、パスワード、Cookieとともに引き続き利用できる可能性があり、これらはすべて公開されて悪用される可能性があります。さらに、Heartbleedを介した秘密鍵の漏洩は、当初はありそうもない、それはそうだった検証済みこの脆弱性を悪用すると、SSL秘密鍵が盗まれる可能性があります。

この方法でSSL秘密鍵が盗まれる可能性があることが確認されているため、Heartbleedの修正は重要です。

この脆弱性は、OpenSSLによるmalloc（）キャッシュのばかげた使用によっても可能になります。折り返すことによってlibc機能し、実際にはメモリを解放しない、libcの悪用対策キックインしてバグを役に立たなくする機会は決して与えられません。

Heartbleedを修正するこれらの方法に関する追加の詳細が利用可能ですここにそしてここに。

そして、その価値については、ここにもっとあります面白い視点。

発見者であるGoogleSecurityのNeelMehtaと、パッチを迅速に提供し、システム管理者がHeartbleedの修正方法を決定するのを支援したAdamLangleyとBodoMoellerに称賛を送ります。また、他のいくつかについて自分自身を教育することをお勧めします一般的なWebセキュリティの脆弱性将来の問題を回避するため。