Debianの弱い鍵の脆弱性につまずいた話

Debianの弱い鍵の脆弱性に引っかかってしまった話

• 2008年3月、著者はEngine Yard（EY）で働いていた
• 当時EYはGitHubに無償でインフラを提供して支援していた
• GitHubの成長に伴い、SSHログイン時間が遅くなる問題が発生した
• GitHubは標準的な方法である ~/.ssh/authorized_keys ファイルを使ってSSH鍵を管理していた
• SSHはユーザーが接続する際、このファイルを開いて、ユーザーが提示した鍵と一致する鍵を線形探索する
• 通常は鍵が数個しかないため問題にならないが、GitHubのようにユーザーが増えると遅くなる

authorized_keysファイルの代わりにMySQL DBを使うことを決定

• 複数の代替案を検討した結果、OpenSSHにパッチを当てて、鍵検索をMySQL DBで行うよう変更することにした
• これは慎重な判断であり、セキュリティを損なわないよう多くの努力を払った
• 2008年4月初めに適用し、SSHログイン速度の問題を解決した

奇妙なことが発生

• 1か月後の5月初め、一部のユーザーが他のユーザーのリポジトリにSSHでアクセスできるようになる問題が発生した
• 調査の結果、異なるユーザー同士が同じ鍵フィンガープリントを持つ鍵を使っていた
• これは鍵を共有していない限り起こらないことだった
• ユーザーたちは互いに面識がないと言い、どうやって鍵が漏えいしたのか分からないと話した
• 他のユーザーの組み合わせでも同じ問題が見つかった
• 共通点は、全員がDebianまたはUbuntuシステムを使っていたことだけだった

原因の究明

• 2008年5月13日、DSA-1571-1の公開ですべてが明らかになった
• DebianメンテナーがOpenSSLの乱数生成コードを整理する際、誤って生成可能な鍵の数を約32,000個まで減らしてしまっていた
• 多くの人がGitHubに登録する際、ベストプラクティスに従って新しい鍵を生成し、その結果衝突が発生した
• その後著者は、既知の弱い鍵を活用して問題のある認証局を見つけるなど、この問題とさらに深く関わることになった

GN⁺の意見

• これほど重要な脆弱性を見つけるには、「おかしい」と感じて粘り強く調査できる時間とエネルギーが必要だ。普通はそんな余裕がないので、運も必要になる
• ほとんどの人は忙しい日常に追われ、問題の根本原因まで掘り下げるのは難しい。私たちの業界がこうした余裕を取り戻すことは重要な課題だと思う
• OpenSSLは最も広く使われている暗号ライブラリの1つなので、この種の脆弱性の影響は非常に大きい。ここにはオープンソースの長所と短所の両方がよく表れている
• こうした脆弱性を防ぐには、コードレビューとセキュリティ監査を強化し、重要な部分の変更はより慎重に検討すべきだ。しかし完璧な方法はない
• それでもオープンソースには、専門家が直接コードを調べて問題を見つけられるという利点がある。クローズドなプログラムではそれすらできない

[GN⁺]

Hacker Newsの意見

• Luciano Belloは偶然CVE-2008-0166の脆弱性を発見したが、当時のIRCログによれば多数の素数が必要で、毎回同じ数が得られたわけではなかった
• 業界全体としては運が良かったように思える。というのも、適切なタイミングで大きな違いを生み出せる技術と時間、エネルギーを持った人がいたからだ。これは「多くの目」と「日光は最良の消毒剤」という考えを実感させる場面でもある。誰かが偶然バグを見つける確率がどれほど低くても、人は実際にそれを見つけることがある。一方で、プロプライエタリ／クローズドソースのコードではその確率は0だ
• この脆弱性を引き起こした変更は、慌てて行われたものではなかった。メンテナはOpenSSLメーリングリストで問題を提起し、フィードバックを求め、解決策を提案しており、upstreamを含むいくつかのフィードバックも得ていた。結果はひどい脆弱性になったが、これは誰一人として問題に気づけなかった、非常に不運な事例に見える
• GitHubは、MySQLデータベース内でキーフィンガープリントを索引にしてキーを参照できるようOpenSSHにパッチを当てるのが最善の選択肢だと結論づけた。~/.ssh/authorized_keysへのアクセスを高速化しようとしていた状況では、SQLiteではなくMySQLが力を発揮できる種類のケースだったようだ
• これは、人気のあるビットコイン用ハードウェアウォレットのシード生成関数で同じことが起こる可能性と、その影響について考えさせられる
• GCDを使って共通のpまたはq因子を持つRSA鍵を検出した話も興味深いエピソードだった
• SSHログイン時間が遅いことが、さまざまな理由で引っ張る価値のある手がかりになり得ることがわかる
• OpenSSLのRNGは未初期化のスタックメモリとPIDでシードされていたが、Debianパッチがなかったとしても、PIDだけでシードすること自体がすでにかなり危険だったように見える
• GitHubが今でもパッチ済みのOpenSSHを動かしているのか気になる
• Ezra ZygmuntowiczがGitHubを筆者に紹介し、GitHubチームと一緒に問題を掘り下げる時間を与えてくれた、という一文が面白い。GitHubチーム自体に大きな問題があるかのようにも読めるからかもしれない
• Lucianoが発見していなかったら、あとどれくらい長く見つからなかったのだろうかと気になる。偶然に発見できたのは、GitHubや大手クラウドプロバイダのように、ユーザーから何千もの鍵を保存している数少ない場所だけだったのではないかと思う