Heartbleed開発者曰く、OpenSSLのバグは意図的なものではない 83
ストーリー by headless
不運 部門より
不運 部門より
諜報機関の関与も疑われているOpenSSLの「Heartbleed」バグだが、原因を作った開発者は意図的なバグの挿入を否定し、開発時のミスだと説明している(Deutsche Telekomの記事、
The Sydney Morning Heraldの記事、
PC Proの記事、
The Globe and Mailの記事、
本家/.)。
この開発者は当時ドイツ・ミュンスター大学の大学院生で、現在はDeutsche Telekomに勤務している。大学ではOpenSSLを使用した研究を行っており、研究の一環としてバグフィックスや新機能などでOpenSSLプロジェクトに貢献していた。しかし、彼がコードを書いたTLS/DTLSのHeartbeat拡張では、特定の変数に格納されたデータが正しいかどうかをチェックしていなかったという。そのため、不正な値を入力することで、メモリー上のデータを意図した長さ以上に読み取ることが可能になっていた。このミスは不運にもコードレビューで発見されることはなく開発バージョンに追加され、その後公式にリリースされてしまったとのことだ。
この開発者は当時ドイツ・ミュンスター大学の大学院生で、現在はDeutsche Telekomに勤務している。大学ではOpenSSLを使用した研究を行っており、研究の一環としてバグフィックスや新機能などでOpenSSLプロジェクトに貢献していた。しかし、彼がコードを書いたTLS/DTLSのHeartbeat拡張では、特定の変数に格納されたデータが正しいかどうかをチェックしていなかったという。そのため、不正な値を入力することで、メモリー上のデータを意図した長さ以上に読み取ることが可能になっていた。このミスは不運にもコードレビューで発見されることはなく開発バージョンに追加され、その後公式にリリースされてしまったとのことだ。
っ ハンロンの剃刀 (スコア:5, すばらしい洞察)
ハンロンの剃刀 [wikipedia.org]で十分っしょ。
C言語でこの手のミスはありがちだから、陰謀論よりも単にあぁやっちまったのか…という印象が。なぜレビューでバグが見つからなかったのか？うるせえPMみたいなこと言うんじゃねえ！
＃ この中でバグを埋め込んだことがないものだけが彼に石を投げよ！
Re:っ ハンロンの剃刀 (スコア:5, おもしろおかしい)
主よ、使う専門のユーザーである私は投げてよいのですね。
# 石を投げるのがそもそもダメです。
Re: (スコア:0)
使う専門のユーザーは幸いである。汚染とか感染とか気にする必要がない。
Re: (スコア:0)
意味が分からない。説明希望。
Re:っ ハンロンの剃刀 (スコア:3, 興味深い)
オフトピで野暮な解説になってしまいますが
マタイ福音書の「…はさいわいである」
というのは最下層のみじめな生活をしている人向けなわけです。
そんな人をさいわいであると祝福することば。
そういう趣旨であれば、使う専門のユーザーは
(涙と嗚咽のためこれ以上書き進められません。ごめん)
Re: (スコア:0)
> オフトピで野暮な解説になってしまいますが
> マタイ福音書の「…はさいわいである」
それ「誤訳」で、有名な箇所では？
luckyじゃないからね (スコア:2)
英語だと blessed だからなぁ。
幸いである、って言われると Lucky guy! みたいな感じがする。
屍体メモ [windy.cx]
Re:っ ハンロンの剃刀 (スコア:5, すばらしい洞察)
レビューで見つからなかった以上はプロジェクトの失敗であって個人の失敗ではないよねぇ。
なんか実装者の今の勤め先まで晒して追いつめるようなことしなくても…
作っちまった自覚が本人にあればそれだけで反省するには十分なんだから。
Re:っ ハンロンの剃刀 (スコア:4, 参考になる)
Re: (スコア:0)
だよねぇ。
そこで静的解析ツール導入してチェックを必須にするとか、レビュー項目のダブルチェックしますとかそういう方向に行かなきゃ。
海外も八つ当たりの人柱を求めるんですねぇ(小並感)
Re:っ ハンロンの剃刀 (スコア:2)
結局のところ「人がやっている以上たとえ巨大なコミュニティであってもチェック漏れは起きる」という例を示しただけなんですよね。
openDoe-Ming Ver.0.72.9beta
Re:っ ハンロンの剃刀 (スコア:1)
Re:っ ハンロンの剃刀 (スコア:2)
小さなコミュニティなんでしょうねえ。
これこれの環境でcompileしたらかくかくしかじかのerrorが出ました
みたいなメールを10年以上前にopenssl-usersに投稿したことが１ぺんありましたが
次直す(意訳)という返信がその日のうちにありました。
patch作成するだけの能がなくてもそれくらいはできるわけだけど
日本人の(と思われる)投稿は当時も今もめったにみない。
openssl-devとopenssl-cvsは見ていないけど。
Re: (スコア:0, フレームのもと)
どこぞの国の超一流研究所で最近起こった事件のことですね（笑）
Re: (スコア:0)
とはいえ、日頃お世話になってるものを作ってくれた人を
平然と無能と呼べるような人間にもなりたくないしなぁ。
Re: (スコア:0)
ダジャレの応酬で酷いことになっているかと思いきや、そんなことはなかった。
リーナスの言った言葉を思い出せ! (スコア:5, すばらしい洞察)
その疑いの目は、ソースコードに向けるべきだろう？
セキュリティを気にする設計ってむずかしい。。。 (スコア:3, 参考になる)
そういえばこんな翻訳記事を見つけた。
"BLUISH CODER: 安全なプログラミング言語を使って heartbleed を防ぐには"
https://github.com/jats-ug/translate/blob/master/Web/bluishcoder.co.nz... [github.com]
Theo師匠お怒りだってよ (スコア:3, 参考になる)
http://cpplover.blogspot.jp/2014/04/theo-de-raadtietf.html [blogspot.jp]
ざっくりいうと…
もともとＴＬＳでハートビートは不要で、ＴＣＰハートビートを使うか、アプリケーションでハートビートを送れ
使ってない機能だから穴があいていても気づかない
ＴＬＳワーキンググループが無能だから要らない機能策定をしている
Re:Theo師匠お怒りだってよ (スコア:2, すばらしい洞察)
セキュアなモジュールに冗長なユーティリティを入れたがること自体が致命的なヒヤリハットですね。
Re:Theo師匠お怒りだってよ (スコア:1)
OpenMGファイル, OpenSolaris, Opening Sale...
記事タイトル (スコア:2)
記事のタイトルが「Heartbleed開発者……」となってるんだけど、これだと記事内容とは逆に意図的にバグを埋め込んだように見えるような気が。
Re:記事タイトル (スコア:1)
で、「レビューで見つからなかった」はどうすんのさ (スコア:2)
割りと根本的に、オプソのあり方に石を投げ入れる問題と思うんだけど…。
完璧なものなど滅多にあり得ないとはいえ、「長年実績のあったソフトウェアに途中から致命的なバグが入り、かつそれがレビューで発見されませんでした。」
って言われて、はいそうですかで終わらせるなら、オプソのほとんどが危険で使えない事になっちゃいますよ。
Re:で、「レビューで見つからなかった」はどうすんのさ (スコア:1)
ソースをクローズドにしてるとレビューで見つかるの?
# 危険が100%無いモノなんて存在しないよ
Re:で、「レビューで見つからなかった」はどうすんのさ (スコア:1)
完全オフトピで恐縮ですが。。。
http://www.openssl.org/source/repos.html [openssl.org]
The OpenSSL package is developed in a Git-based repository. It is available via Git mechanisms at git.openssl.org and as snapshot tarballs through FTP on ftp.openssl.org for those people who either want to always stay at the bleeding edge or even want to participate in the development of OpenSSL. But use such repository snapshots only when you like to see OpenSSL dump core and you can help yourself in case of problems, of course.
クローズドではない状態が15年くらい保たれているはずです(CVSメインがいつからGITメインに移行したのかは忘れた)。
Re: (スコア:0)
そんなこと書いてないのでは？何か難しく考えすぎじゃないの?
恐らくは目が多いことで誤りがクローズドより発見されやすいのだ(故により安全)という
主張がなされることに対する疑問でしょう
メジャーなソフトでかつ何年も放置されていたのだから、
たまにはあるさ例外的なことだとは片づけにくいのではという指摘だと思うよ
Re: (スコア:0)
OSSが安全と思うやつが悪い
ソースを確認できる、ただそれだけのこと
Re: (スコア:0)
>>ソースを確認できる、ただそれだけのこと
？？
それ以上なにを求めることができる？
Re: (スコア:0)
なら危険で使えない人は使えない、使える人は使えるというだけのこと
Re: (スコア:0)
http://it.srad.jp/comments.pl?sid=628761&cid=2581261 [srad.jp]
こっちを読む限り、OpenSourceの問題というより、IETFの問題という主張がある模様。
I
Re: (スコア:0)
使ってない機能だからレビューが適当でバグ入りでもコミットされちゃうし、目が向きませんって事ですか？
それじゃ不味いでしょう。
Re: (スコア:0)
オープンソースではコードレビューくらいでテスト仕様書など作らないもの？
Re: (スコア:0)
その返しは馬鹿過ぎる。
ネットワーク関係ではCを使わないという手 (スコア:1)
セキリティへの影響が大きいソフトはCで書くな、生のポインタ使うな、
C++のコンテナで包め、オーバーフローは自動的検知させて例外を飛ばせ、
いつもそう思う。
Re: (スコア:0)
理想はごもっともですが、C++はおろかいまだに言語仕様完全準拠のCを使えない環境もあるわけで。
Re: (スコア:0)
いろんな意味で、重い理想だね。
攻撃増加中？ (スコア:1)
国内でもHeartbleedを狙うパケットの増加を観測 [atmarkit.co.jp]
「JPドメインでは1195サイトのうち534サイト (45%) に脆弱性あり」「4月9日以降、実証コードと一致するパケットが多数観測された」ということで、管理者が試している分があるにしろ、攻撃も始まっていると考えるべきですよね・・・実際に情報を盗めることを確認、みたいな記事も見かけましたし。
まあいずれにせよ、NSAには既に全部抜かれた後みたい [bloomberg.co.jp]ですけど。
こりゃまだあるぞ (スコア:1)
以前Debianのメンテナだったかが、ランダム性のもとになっている情報をエラーが出るからと削ってしまって、SSHの鍵を大量破棄しなきゃならない事件があったよね。暗号化はスピードも必要だし、中の人たちにとっても難解で、それでいて影響も大きい。コードの質を保つのが難しいんじゃないかな。
ではレビューアーが (スコア:0)
意図的にスルーしたのではないか？あるいはユーザーが意図的に(ry
Re: (スコア:0)
入った理由がどうであれ、NSAが意図的に利用していたことはすでに判明している
CIAはこの手法を昔使っていた (スコア:0)
この手法が何という言葉だったか忘れたけどそれのプログラミング版ですね。
Aを行うプログラムのコードを書きつつ中に機能Bも行うコードをバグとして入れる。
機能Bは他人がコードを読んでも気づかれないか気づかれたとしてもバグと言える。
そういうプログラミングの大会もあったと思います。
日本でも「秘書がやった私は知らなかった」という形でよく使われてるか
Re:CIAはこの手法を昔使っていた (スコア:5, 参考になる)
> そういうプログラミングの大会もあったと思います。
Underhanded C code contest ですかね。
http://underhanded.xcott.com/ [xcott.com]
不定期にしか開催されていないのですが、過去入賞者のエントリはどれも簡潔で、さも悪意がないかのように見える悪意に満ちたバグに富んでいます。これを見ていると逆に今回のバグは見つけやすい方だなぁと思えるので、私は陰謀論に与したくないですねぇ。
Re: (スコア:0)
これです。ありがとうございます。
バグの形である機能を盛り込むノウハウなんかがあると対策は難しいでしょうかね。
Re: (スコア:0)
> 日本でも「秘書がやった私は知らなかった」という形でよく使われてるか
本当に「よく」使われてる？
もし数を数えてみたんなら、もういっぺん数えなおしてみなよ。
Re:CIAはこの手法を昔使っていた (スコア:1)
>Aを行うプログラムのコードを書きつつ中に機能Bも行うコードをバグとして入れる。
>機能Bは他人がコードを読んでも気づかれないか気づかれたとしてもバグと言える。
「なんかの手法のプログラミング版という主張」を書きつつ、「秘書がやる私は知らなかったという
ことが多いという印象操作」をバグとして入れる。
「秘書がやる私は知らなかったということが多いという印象操作」を読んでも
印象操作と気づかれないか気づかれたとしてもバグと言える。
...よく気づいたな。
Re: (スコア:0)
「秘書がやる私は知らなかったということが多いという印象操作」を読んでも
印象操作と気づかれないか気づかれたとしてもバグと言える。
...よく気づいたな。
ちょっと違います。
私はそういう印象操作を狙ったわけではなくてその手法が色々な形で使われているという例を挙げたかっただけです。
私が言いたかったことはそこにはなくそのようにコードを書くこともできるという事です。
Underhanded C code contest を見て頂ければわかっていただけるはずです。
と私が書けばこの手法は完成です。
Re:オープンソースに「貢献」なんてするもんじゃないな (スコア:2, すばらしい洞察)
オープンソースに対する貢献って、報酬を求めてするものではなく今までのバージョンや他のオープンソースに対する謝礼として行うものですよ？
Re:オープンソースに「貢献」なんてするもんじゃないな (スコア:1)
まじレスで野暮だけど、ちょっとだけ目が覚めた思いがした。
そうだよね、元々ＯＳＳってのは、感謝の連鎖で成り立っているよね。
意外と忘れそうになるけど。
Re:オープンソースに「貢献」なんてするもんじゃないな (スコア:1)
昔はそうだったけどねぇとOpenBSDの人たちが言っています。
https://www.mail-archive.com/tech@openbsd.org/msg17420.html [mail-archive.com]
FreeBSD系にだけOpenSSHのセキュリティホールがあるけど教えない、それは
https://www.mail-archive.com/tech@openbsd.org/msg17433.html [mail-archive.com]
十年前と違って、フルディスクロージャーによる発展という理想がすでに崩壊しており、
今はスポンサーにアーリーアクセスを与えてダンマリを決めこむことで金をもらう時代だから。
スポンサーのいるプロジェクトはクリーンなコードベースなんぞ求めておらず、
バグがあればあるだけ嬉しいはずだ、と。
教えても「チッ、公開しないでおいてくれればマネタイズできたのに」と言われるなら
そりゃ教えたくないですね。