LibreSSL Portable 2.0.2リリース、PRNGの脆弱性を修正 30
ストーリー by headless
修正 部門より
修正 部門より
Open BSD Projectは15日、LibreSSL Portable 2.0.2をリリースした。このバージョンでは疑似乱数生成装置(PRNG)の脆弱性が修正されている(Andrew Ayer氏のブログ記事、
Threatpostの記事、
本家/.)。
この脆弱性は、fork()を実行してプロセスをコピーした場合、孫プロセスと元のプロセスのPIDが一致するとRAND_bytesが同じデータを出力するというもの。LibreSSLではPIDを使用してforkされたプロセスかどうかをチェックし、自動的に再シードを実行する。親プロセスと子プロセスのPIDが一致することはないが、forkを繰り返した場合、元のプロセスとPIDが一致してしまう可能性がある。同様の問題はOpenSSLでも見られるが、RAND_pollを実行することで明示的な再シードが可能となっている。脆弱性を発見したOpsmateのAndrew Ayer氏が使用したテストプログラムでも、fork後にRAND_pollを実行しているという。しかし、LibreSSLではRAND_pollがno-opとなっており、明示的な再シードが実行できない。この脆弱性についてAyer氏は最悪のミスだと考えているようだが、OpenBSDのTheo de Raadt氏やBob Beck氏は現実のプログラムでこのような処理が行われることはないとし、問題が誇張され過ぎていると述べているとのことだ。
この脆弱性は、fork()を実行してプロセスをコピーした場合、孫プロセスと元のプロセスのPIDが一致するとRAND_bytesが同じデータを出力するというもの。LibreSSLではPIDを使用してforkされたプロセスかどうかをチェックし、自動的に再シードを実行する。親プロセスと子プロセスのPIDが一致することはないが、forkを繰り返した場合、元のプロセスとPIDが一致してしまう可能性がある。同様の問題はOpenSSLでも見られるが、RAND_pollを実行することで明示的な再シードが可能となっている。脆弱性を発見したOpsmateのAndrew Ayer氏が使用したテストプログラムでも、fork後にRAND_pollを実行しているという。しかし、LibreSSLではRAND_pollがno-opとなっており、明示的な再シードが実行できない。この脆弱性についてAyer氏は最悪のミスだと考えているようだが、OpenBSDのTheo de Raadt氏やBob Beck氏は現実のプログラムでこのような処理が行われることはないとし、問題が誇張され過ぎていると述べているとのことだ。
2.0.3がでてる～ (スコア:2)
http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ [openbsd.org]
そんなことより (スコア:1)
そんな修正済みのことより
/dev/{u,}randomがなくても乱数を取れるようにLinuxでも対応しようとしてる件
http://thread.gmane.org/gmane.linux.kernel.cryptoapi/11666 [gmane.org]
のほうが面白いよ。やっぱLinuxとBSDの違いはカーネルに顕著だね
オフトピだけど (スコア:1)
やっぱLinuxとBSDの違いはカーネルに顕著だね
BSD信者ほど、この手の指摘を得意気にしてくるけど
BSD界隈には、cgroupsやfanotifyが存在しない件についてはどう考えてるの？
と、先日のX.Org 1.16のリリースノートを見ていて感じた
GNOMEのみならず、X.Orgまでもがsystemd統合してくるようだと不味いんじゃないの？
GNOMEだけなら、一切合切を使わなければ済む話だけど、X.Orgまで統合しだすようだと
色々なサーバアプリ群までもがsystemd対応を初めかねない
まあ表立って対応しなくとも、PIDによる監視なんてアレなやり方は、どんどん淘汰されてくんじゃいのかな
しかしそれやられると、cgroupsやfanotifyのないBSD界隈は時代遅れになっちゃう
それを逃れる為にはcgroupsやfanotify的機能をカーネルレベルに実装しつつ
今更GNUなsystemdを持ってくるわけにもいかないから、systemdの代替的なサービスアプリもこさえなきゃなんない
そういった、時代に取り残されない為に通らなきゃならない茨の道が、これから先に待ち受けてるというのに
BSD界隈の連中は、どうしてあんなにものほほんとしていられるんだろう・・・・・
#「bindがunboundになってた」とかいってグダグダ議論してる場合じゃないだろ？
Re:オフトピだけど (スコア:1)
よく分からないんだけど、X が systemd 経由で起動するようになったら startx コマンドがなくなるとか、xinit コマンドが無くなったりするんですか？
[Q][W][E][R][T][Y]
乱数対応の話をえらく拡張してますが (スコア:1)
オプトピのオフトピだけど (スコア:0)
bindがunboundになってgdgdする環境にX.Orgをインスコしないとかあり得ない、と空目した
BSD
狂教の人達にそれを強要するのは結構骨が折れそうだｗ頑張って危険が危ないと啓蒙してあげて下さい
Re: (スコア:0)
×初める
Re: (スコア:0)
「初めて」からわざわざ1文字削除して打ちなおしたのだろうか
Re: (スコア:0)
初め+る
Re:オフトピだけど (スコア:1)
SKKかな
Re: (スコア:0)
改行がなくて読みづらい。
Re: (スコア:0)
> #「bindがunboundになってた」とかいってグダグダ議論してる場合じゃないだろ？
笑った。確かにね。
Re: (スコア:0)
そういう風になってはいけないの？
それぞれ好きにすればいいと思うんだけど、時代遅れになるからダメだと言いたいの？
時代遅れになることを真っ先に自分に聞こえるように議論しろ（しているのは聞こえないようだから）と言いたいの？
こういう何が言いたいのかわからない、自分の主張なり好みをうまくくるんで隠して
何かを突っつきたい人がいるから面白いんだけど。
自分はLinuxで件の対応をしてる立場だけど、そうじゃないのがあってもいいんじゃないの？
Linuxだって時代遅れのところいっぱい内包してるよ
かなり恥ずかしい (スコア:1)
> この脆弱性についてAyer氏は最悪のミスだと考えているようだが、OpenBSDのTheo de Raadt氏やBob Beck氏は現実のプログラムでこのような処理が行われることはないとし、問題が誇張され過ぎていると述べているとのことだ。
OpenSSLをさんざんdisっておいてこれでは説得力なさすぎだろ……。CVE-2014-0224も結局OpenSSLに修正コミットが入るまで見つけられなかったようだし。やっぱり開発リソースを無駄に分散させただけになりそうだ。
Re:かなり恥ずかしい (スコア:2)
OpenBSDの連中を擁護するわけじゃないけど「まず掃除しないとどうにもならん」ってのが彼らの主張で、その途上だと理解しています。彼らを持ってしても、多少はあるでしょう。ましてやportable版ですからね。
カッコ悪いのは確かだと思うけどさ。
Re: (スコア:0)
ていうかOpenBSDの旧来の主張ではLinuxでセキュアなRNGは無理っていう話なんだから
portableを出したり非現実的なケースまで修正したりするのはすごい譲歩だよな
Re: (スコア:0)
最初の発表だとOpenBSD5.6と一緒にリリースとだけ
書かれてたので、前倒しでportable版リリースしつつ
Linux用のcompatのソースまで出してきたのは嬉しい誤算。
Re: (スコア:0)
セキュアプログラミング技術と暗号技術はちょっと違うと思うんだよね。科学者と数学者の違いみたいな。
どちらも協力しあって総合的に良いものができればみんなハッピーさ
Re: (スコア:0)
いいわけととるとアレだけど、実際の影響度を説明するならそんなもんだろうと。＞現実のプログラムでこのような処理が行われることはないとし、問題が誇張され過ぎている
まだまだユーザが少ないうちから積極的に修正プロセスが機能していると喜ぶべきところじゃないかな？
Re: (スコア:0)
＞ OpenSSLをさんざんdisっておいてこれでは
disってましたっけ？
猿が書いたんだろとは言ってたけど、
CVEを出すとは恥ずかしいという非難はしてないと私は思ってましたが。
脆弱性のあるコードをリリースしたのは良くはないけど
指摘する人がいて、それをすぐに修正する人がいて、
オープンソースってこういうところがいいんだよなって
感じるニュースだと感じたけど、これをもってLibreSSLは大丈夫か？
という記事や論調が意外なほど多くて驚いてます。
Re: (スコア:0)
forkしたときは乱数のシードを再設定するというのは、かなり基本的なノウハウだからじゃないでしょうか。
今回はユーザがRAND_pollを呼び出してもエラーにもならず、黙って無視されていたようなので、なおさらよくないですね。
ぱっと見「恥ずかしい」バグに思われても仕方ないかも。
#実際のリスクがどの程度なのかはしらん。
Re: (スコア:0)
有名なバッドノウハウで、しかもセキュリティホールの原因になりうるならば根本をつぶすべきと考えたのでは。
LibreSSL にて、PID変更を検知して再シードするって書いてあるし。
実はこれを「恥ずかしいバグ」って言っているほうが、セキュリティに対する感覚のなさを暴露しているのかも……よ？
# theoにはついていけないZE! ってだけかも
Re: (スコア:0)
>猿が書いたんだろとは言ってたけど、
これがバカにしてないとあなたはいうのかいな？
俺たちの方が良いコードかけるぜと言って書き直したら
実装忘れか消しすぎかわからないが、バグ入れたのだから
何それという話になるのは仕方ない。
コードは綺麗なのかもしれないが、エンジニアリングとしては下なんじゃないかとね。
Re: (スコア:0)
「CVEを出すとは恥ずかしい」とdisってはいなくて、
猿が書いたのかと言いたくなるくらい管理されていないコードベースを
disってたのですよ。
この二つはdisってる対象が全く違いますよね。
あとOpenBSDチームは、「 俺たちの方が良いコードかけるぜ」
という傲慢なことは発言してないと思います。
バグも脆弱性もないコードを自分達だけで作り出せるとは言えないことを
彼らはよくわかってるからです。
Re: (スコア:0)
管理されてないコードベースとはどういう意味なんでしょう？SCS使ってないとかそんな話?
大変に読みにくいとか冗長で無駄だとか、いわゆる汚いコードだとして、「猿が書いた」と言ったのではないのかい?
自分ならもっと良く書けるという意識がなければ汚いとならないのだから、
具体的な言葉として言ってなくても、下に見ているのは明らかと思います。
OpenBSDの人たちはコード評論家であってコード書かないのなら話は違いますが。
もし自分たちのコードの方が良くなると思ってないのに書き直してるのなら、その方が理解不能です。
キリスト教の文化圏で人を動物に例えるのは知性の欠如を意味し相当な侮辱です
その相手は回避して対応していた問題に自分は落ち込んだわけで相当カッコ悪いわけで、いろいろ言われるのは仕方ないでしょう
Re:かなり恥ずかしい (スコア:1)
ここに Bob Beck 氏のスライドがあって、OpenSSLのソースが
どんな状態だったか、どんな管理状況だったかなどがまとめられてます。
http://www.openbsd.org/papers/bsdcan14-libressl/ [openbsd.org]
8ページに端的にまとめられてますが、
外部の参加者がくじけるほどのソースであること、
バグ管理システムに記録されたバグが修正されず放置されていること、
が挙げられてます。
これを「管理されてないコードベース」と書きました。
前述のリンクを読んでない方には伝わらない書き方でしたね。
ちなみにOpenSSLが最近出したロードマップでもこれらは課題として挙げられてます。
https://www.openssl.org/about/roadmap.html [openssl.org]
3と4がソースの汚さで、1がバグ放置ですね。
OpenBSDのチームは、OpenSSLに脆弱性のバグがあったことを非難したのでなくて、
外部の参加者を挫くほどのソースコードにしてしまったこととバグ放置を非難したのです。
だからLibreSSLのソースコードがOpenSSLに比べて汚くてバグ放置したのなら、
「OpenSSLに対してあんなエラそうに言ってたのに恥ずかしい」
と非難すればよいと思います。
「OpenSSLが出してないバグを作りこんだからLibreSSLは恥ずかしい」
というのは非難のポイントがずれている、ということを言いたかったのでした。
ところで、サルが書いたのかとか言ったのは侮蔑的で、そんなこと言わなきゃいいのに
と私は思ってます。
Re: (スコア:0)
> 指摘する人がいて、それをすぐに修正する人がいて、
> オープンソースってこういうところがいいんだよなって
…ならなかった人達がLibreSSLを立ち上げたんですよね。
人を叩かばムチ2本。
Re: (スコア:0)
＞CVE-2014-0224も結局OpenSSLに修正コミットが入るまで見つけられなかったようだし。
そもそも脆弱性を見つけるための活動じゃなかったのだし当たり前では。
それをあげつらって何を言いたいんでしょうか。
LibreSSLのチームは無能だとでも言いたいのですか？
＞やっぱり開発リソースを無駄に分散させただけになりそうだ。
OpenSSLの開発リソースとLibreSSLの開発リソースは
元々別々なのだから、開発リソースを無駄に分散させたは
おかしいのでは。
一つの開発リソースだったのを二つに分散させたのでは
ないのですから。
2.0.4が出てる～ (スコア:1)
http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ [openbsd.org]