More Related Content
Similar to 俺とHeartbleed
Reproducebility 100倍 DockerマンNagi Teramo
初心者がOpenIndianaで自宅サーバを作ったよって話Masataka Tsukamoto
Emscriptenと不思議のダンジョン兎 伊藤
Osoljp201204Masataka Tsukamoto
IT業界における伝統芸能の継承 #hachiojipm鉄次 尾形
composer-scriptsについてHiraku Nakano
More from Masayuki KaToH
APAC Community Summit DevOps Breakout 部屋.pptxMasayuki KaToH
LINE × AWSの可能性や事例について語り合う夕べMasayuki KaToH
俺と Active Storage + CloudFrontMasayuki KaToH
俺とオープンデータMasayuki KaToH
CapacitorMasayuki KaToH
俺と最近のクラウドAI系サービスMasayuki KaToH
俺とHeartbleed
- 2. Profile • Name • ふぁらお加藤 / PharaohKJ • Job & Works • PhalanXware (Freelancer) • OCR system .com / .net • ISDB-T MFC / Linux C++ • Social Game PHP / Java • SNS • twitter - @PharaohKJ • facebook - pharaohkj
- 3. 最近やってます VisualStudioはMicrosoftのTM/登録商標です OpenGLはKhronosのTMです しばらくC++やってなかったら どこまでが標準ライブラリなのやら・・・。
- 4. HeartBleed概要 • SSL実装のひとつであるOpenSSLで実装ミスがあり、セ キュリティホール。大騒ぎに。 • HeartBeat 死活確認の実装ミスで 64kのメモリを問い合 わせ者に返事してしまう。 • 今日は、HeartBleedとSSLを理解するために、SSLにつ いて自分でまとめてみた。
- 5. About SSL / TLS • SSL? TLS? 詳しい経緯はwikipediaでも参照 • RFC2246 Transport Layer Security • 「認証」「暗号化」「改ざん検出」の機能を提供
- 6. SSL / TLS Layer • OSI参照モデルでいう セッション層でこれより 上位に機能提供できる • https とあったらSSLを 用いた http というこ と。ftps とか telnets と か ircs とか pops とか 図はシマンテック社さまより 下記ページより引用 http://www.symantec.com/ja/jp/ page.jsp?id=how-ssl-works
- 7. 共通 暗号 • 普通の といえばコレ。 • １つの 穴があれば、１ つの 。 • この で、開け閉めを行 う。 • の形がバレたらみんな バレる。 バレ禁止
- 8. 公開 暗号 • １つの 穴につき、開け るよう・閉めるよう2つ ペアの 。 • 閉 で閉めたら、ペア開 で開ける。 • 閉 の形がバレても開け ることができない！ • 両方バレたらバレる。 片方はバレOK
- 9. サーバ証明書 • 俺は北斗神拳伝承者 ケンシロ ウ様だ。マジ？ • 「胸に７つの傷」を持ってるし 本人だ。(みんな知ってる公開 情報だけど) • この人がケンシロウかは信頼で きる人にきけばよい。 • つまり渡された閉 が、ご本人 の かどうかは信頼できる第三 者が証明しておくということ。 http://www.hokuto-no-ken.jp/hokuto_archives/jagi.htmlより引
- 10. SSL/TLS Protocol 1. いまからAmazonさんで通販をしましょう。 2. Amazonさん、インターネットという犯罪者の巣窟に私のデータが流れ るので秘密の会話 https を希望します。 をかけて送るので閉 くださ い。 3. わかりました。閉 +証明書もつけます。 4. 閉 +証明書を受け取りました。ベリサインさん、この証明書有効です かね？ 5. 有効です。私のところに登録あります。 6. 確認できたので、閉 使って今回限りの共通 、閉めて送ります。 7. 開 を使い 共通 受け取りました。それではよろしくお願いします。
- 11. TLS Heartbeat • RFC6520 の 死活確認プロトコル。 • さっきの例の Amazonさん と お客さん の通信間で、「まだつ ながってる？元気？」というのを双方で確認するプロトコル。 • プロトコルとしては「死活確認！のあとに送った言葉をオウム 返しせよ」という内容。 • お客さん「死活確認！元気ですか？」 → Amazonさん「元気 ですか？」こんな流れ。
- 12. その実装 • OpenSSHでは、死活確認！と言われたら送られてきた データをmemcpy でコピーすることでオウム返しをす る。 • memcpyというのは 読んで字のごとくメモリーのコピー を行うこと。 !
- 13. Heartbleed • メモリーのコピーするとき何バイトコピーするかは実は プロトコルで言うことになっている。 • 「死活確認！元気ですか？以上６文字！」 • ここでお客さんが「死活確認！元気ですか？以上100文 字！」と言ったら・・・ • memcpyで「元気ですか？」のあと、残り９４文字をメ モリのどこかからコピーし、返事してしまう。
- 14. Heartbleed • HeartbeatMessage::payload_le ngthはuint16と定義されてい る。 • uint16 は 16bit 整数、最大値は 65,535 = 64k • なので、お客さんのフリをした 人が、「死活確認！あ！以上 65,335文字！」と言い続ける と・・・ • 「あ！」のあと65,334文字返事 してしまう。という大出血。
- 15. Heartbleed • 漏れたデータの先に、ペア開 があったとしたら・・・。 • 両方バレたってことやん！オ ワタ • それどころか、http応答してい るプロセスの読み込んでいる ものが全バレの可能性がある。 • ていうかバレてる前提で動く べき。
- 16. まとめ • 死活確認という単純で失敗することがあるある前提なプロトコルの実装 にバグがあった。 • その結果、問い合わせに対して応答するアプリのメモリをuint16分相手に 送っていた。たいていの場合、応答するアプリは秘密情報満載。 • 暗号方式でバレていない前提のものがちゃぶ台返しになってしまったの で、大変なことに。 • memcpyとか気をつけましょう。Microsoftならmemcpy_sとかあるんや で？ • 今回はOpenSSLという実装の問題であり、ソレ以外のSSL実装は対象 外。