OpenSSLの重大なバグって

いくらお前らでも対策できないよな

￣￣￣￣￣￣￣l/￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　 ∧＿∧
　　　　　　　　　( ´･ω･`) 　　 　∧＿∧
　　　　　　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
　　　　　.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
　　　　　||＼　￣￣￣￣　　 ／ .|　　　|　|
　　　　　||＼..∧＿∧　 　　(⌒＼|_＿./ ./
　　　　　||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　　　　　　/　　　ヽ　空気読めよ　　 ＼| 　 （　　　　）　
　　　　　　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　　　　　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　　　　　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

1.0.1なんて新しいバージョン使ってないし

影響あるのはフリーソフト使ってる奴らだけだろ？
プロプライエタリな俺らには関係ないよ

アプリケーションサーバのSSL実装独自でやってるところあるんだ

Openと名前のつくものは関わらないほうがいい

オープン系(死語)

いや、今まさに対応してきたんだが

>>6
Open XMLフォーマットを採用してるMS Office使えないじゃん

Open XMLフォーマットを使わなければよい

>>10
でもソフトがOpen XMLに対応している

OpenSSLの脆弱性を含んだライブラリーを使った市販の製品もあるから、
クライアント側では、それらも対策しないといけないな。

Windows Server無双

【ネット】暗号化ソフト欠陥、ＮＳＡは２年前から認識−情報収集に利用
http://ai.2ch.net/test/read.cgi/newsplus/1397276668/

>>1
いくらってｗｗ
もともとレゴブロックのように部品をくっつけるしかできないやつが９９％だよｗｗ
部品開発すら出来ない連中なんだからｗｗ

Open-GLはいずこへ。

OpenGL ESなら普通にスマートフォンで使われてるらしい

>>1
ハートビート機構のところの
サイズチェックとメモリの確保のところをいじるだけだぞ・・・・

>>5
普通RSAから買うだろ。

OpenSSLに限らずOpenBSDは遅くても良いから脆弱性を起こさない事を目標にしています。
http://slashdot.jp/story/05/08/25/0917258/OpenBSD%E3%80%81malloc3-%E3%... [slashdot.jp]
投稿からリンクされていますが、このmallocの変更は死ぬ程遅くなるはずです。
しかし、それでもOpenBSDは採用します。

もちろん、速度が欲しい場合もあると思いますが、
必要に応じて選べるのが良いと思います。

速度が必要ならオリジナルのOpenSSLを、SSLで通信しているのを覗かれたくない人はOpenOpenSSLを、と選べるようになってくれた方が嬉しいです。
あなたが覗かれても良いならどうぞOpenSSLを使ってください。
私は覗かれて欲しくないので、良いCPUのマシンとOpenOpenSSLを使います。

結局、自分が対象になってるかはどうやって確認したらいいの？
それとどういう対策が必要？

>>21
確認方法は、opensslのバージョンを確認すること。
主要なディストリならもう更新が来てるはず。パッケージ更新しておけば大丈夫だろ。

これつかうといいよ。
https://github.com/FiloSottile/Heartbleed
OpenSSLが更新されてても、デーモンとか再起動
しないと脆弱なままなので確実に調べるなら
この手のツールでHeartBeatがちゃんと意図した
動作をするか確認するのが確実。

>>23
これつかって他所のサイトを調べたら攻撃と見なされて逮捕とかならないの？

>>23
HeartBleedな

いやこの場合はビードで合ってるだろ。頭悪いのか？

HeartBleedが意図した動作しちゃダメだろ

これがマ板のレベルですよ皆さんｗ

一昨日のＷＢＳで簡単な説明があったな。
クラッカー側が、セッションを始める時点でのやりとりを利用してるとか。

一機にたくさんのリクエストを出すと、つい机の中にある
秘密情報も送ってしまうとか．．．どんだけアホなんだよ。

先生に宿題の状態をせかされて、彼女の「クパ〜♪」画像を
間違って送ってしまい、先生に彼女の股がパイパンだと知られて
しまったみたいな事らしいわ。

>>29
簡単に言うと、OpenSSL 1.0.1 で搭載された生存監視 (Heart Beat = 心臓の鼓動確認) のバグ。

OpenSSL 1.0.1 は、クライアントから報告された生存監視メッセージの文字数分だけメモリを
確保して、その後に送られてくるメッセージを格納し、最後にそのメモリの内容をクライアント
に返している。
----
期待する動作：
クライアント「これから５文字のメッセージを送るから生きてたらそのまま返してね」
　　　　　　「こんにちわ」
サーバー　　「こんにちわ」
クライアント（サーバーとはちゃんと通信できるんだ）
----
期待する動作：
クライアント「これから５文字のメッセージを送るから生きてたらそのまま返してね」
　　　　　　「こんにちわ」
サーバー　　「こん＠＃？」
クライアント（あれ？サーバーとちゃんと通信できないぞ）
----
実際に送るメッセージよりも多い文字数を宣言すると…：
クラッカー　「これから64000文字のメッセージを送るから生きてたらそのまま返してね」
　　　　　　「こんにちわ」
サーバー　　「こんにちわPASSWORD=12345&注文番号=12,34ユーザID=984521...」

最初の５文字は生存監視メッセージだけど、残りの63995文字は、直前まで使われていて
クリアされていないメモリの内容。SSL通信の内容や、SSL通信の暗号鍵とかが入ってる

こんなもんよく今まで誰も気付かなかったなとそちらに驚く

OpenSSLの脆弱性の露呈で、沢山の目にソースが見られているから欠陥がすぐ
わかる、問題は修正される、だから安全というオープンソース安全神話は完全に崩れたよな。

>>30
すげーわかりやすいな
多分ドキュメント作るセンスあるな

>>24
どうだろうな…まったく問題ないという自信はない。もともと
https://filippo.io/Heartbleed/
このサイトの検知サービスのコードで、外部に公開してない
サーバーを調べるのに自分は使った。

>>28
偏差値４５くらいだろプログラマの平均偏差値ってｗ

>>33
どこがだ？
ここはプログラマ板だぞ。
はしょったプログラムのせれば十分だろ

>>35
偏差値ではかれない能力を持ってるのが俺らだろ

>>36
いや、俺は上手い文章だと思うけど。
お客への説明に使えるし
マ板だからって全部プログラムで
書く必要も無いんじゃね？

>>38
とてもわかりやすいよな
これにケチつけるひねくれた性格が、この業界に性格の腐った奴が多いと思われる原因

>>38
いや、うまい文章のまえに、ソースみてみろ。そのままだから。
ソース見たほうが圧倒的に早い。

>>40
いや、本人が自画自賛してるだけだから。

ソース見たら分かるというのは詭弁

オープンソースが安全っていう神話は崩れたな

本当のことじゃないから神話なんじゃないの？

いつまでも古いシステムを人が変わってまでサポートし続けるくらいなら
新しく作りなおしたほうがいいわ

クローズドソースのほうが安全ですという奴は一生WinXP使ってろ

>>46
最新のWindowsはオープンソースなのか？

論理学的には最新のWindowsがオープンソースだろうがなかろうが
WinXPの安全性の真偽の命題には関係ないね。はい次の人どうぞ。

>>48
なんでXPを推すの？

XPとだけ比べて欲しいから。
XPとなら勝てる（それ以降では負ける）と
思っているから。

クローズドソースなら安心という人はXPなんとかして下さいよ

何とかする＝新しいOSにアップグレードする。

どうせLinuxだって新しいOSにアップグレードするだろ？
でGUIとか変えられちまうだろ？
なんもかわらん。

やはり最強は北朝鮮が制作したRedStarLinuxだな

OSSが悪いんじゃなくて
OSSなんかにかぶれてしまう奴の作るものは品質が落ちるだけ。
OSSだから直せない奴が悪いと逃げ続けテストを怠る。
大体、テストなんてつまらんことは、クローズドな環境で
業務に人生がかかってる社畜に無理矢理やらせないとまともにやるわけないだろ。

オープンだろうがクローズだろうが
規模が大きくなれば同じ事。

>>51
バカなの？それとも詭弁を弄してるつもりなの？

OpenSSLプロジェクトはお金と人を入れられるようでなにより
http://www.atmarkit.co.jp/ait/articles/1404/25/news150.html

俺33だが30とは赤の他人だぞ

やっぱオープンソースって開発元がまともにテストしてないし
利用者側もまともにテストしない

こうやって実際の事故からフィードバックしていくから長い目でみれば強固になっていくけど
ユーザーが人柱になっていくという考え方は企業ユース、特にインフラ系には馴染まないのではないだろうか

ドッグフードを食べるって知っているか？

割とよく知られるようになったのは戦うプログラマーあたりからだけど、
テストは万能じゃないから結局使いながらしかないってことなんだけどね。

よくハード屋がソフト屋の品質に対する態度、特に後からネットでアップデートを配信すような行為を嘲笑するけど
ハード屋のミスは自動車会社で言えばリコールなどが起きれば大騒ぎなわけで、
いかにして隠蔽するかという動機がより強く働くようになる。

ドッグフードの話ってのはテストの有効性というより、もっと精神論的な、
自分で使えないようなものは本当に力を入れては作らない（だから使うべきだ）
ということじゃないの？

オプソ信者ってのはやっぱオープンイコール良い事、バグがすくなるなる、
みたいなこと根拠も無いのに言い過ぎたんだと思うよ。

金を取る商品だから、セキュリティ対策は万全にする。どこの馬の骨とも
知れぬやつがレベルの低いコードを混入させる恐れが少ないからセキュリティ
の問題が起きにくいのだ、といっても（その真偽は別として）理屈としては
通るでしょ。
それと同じような実証や調査を経ていない幻想だったんだよ。
オープンソース安全神話。

>>60
テストが万能じゃないからって、テストを放棄していいわけじゃない
そして>>59はオープンソースはドッグフードを食べてないって話をしてるんだよ
そもそもドッグフードを食べる話だってWindowsの事じゃないか

不具合なんかテストで見つけるもんであって
ソース読んで探すものじゃないからな

その後見つかった不具合は
ソース読んで直すんだからな。

脆弱性（不具合）を見つけるとき
ハッカーはソース読むんだからな。

おまえら何の話してんの？

お前ら、ドッグフードにソースかけて食うのか？

おまえらが食ってるのはタコの足だよ

>>25
heartbeatな

どんなに時が早く過ぎてもふたりだけはこのままでいようと誓った

>>32
そんなものはとっくの昔に無いと思う。

>>38
こないだの IE のセキュリティホール騒ぎに比べたら断然説明しやすいわな。

>>72
> >>32
> そんなものはとっくの昔に無いと思う。

ESRの伽藍とバザールもそんなこと言ってないがね。
だから「神話」なんだろうが。

しかしきたねーわかりにくいソースだなぁ

だかそれがいい。

また脆弱性きたです

うわー月曜行きたくねえ。

果たしてTheoは救世主となるか?

TheOpenSSL 2.0まだー？

>>66
半分間違い。
実際にそれをよくやってる俺に言わせてみれば、コードを読んで「これ、バグだろ」って思うことは絶対にない。
動作をさせてみて、変な動作に気が付いて、デバッガでプロセスにアタッチしながらソースを見る。
そうやって、データの変化を見て、あれ？ここの処理？？みたいな感じで発見に至る。

>>80
それは君の能力が足りないだけでは。

>>81
違うよ

>>82
やっぱり能力不足だ（確信）

652 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 03:18:05.44 ID:mldN4Sgm
(略)Heartbleedはサーバ側のバグであって (略)

654 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 04:32:12.49 ID:HzuQuOzg
>>652
(略)Heartbleedバグはクライアント側でも発症するバグだから理解が足りてないよ。 (略)

655 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 06:24:45.46 ID:cWXGt/QO
>>654
(略)もう一度言うけどサーバ側のバグだからね
バグのあるサーバを悪用すればクライアントから情報を引き出すこともできるので
新しい鍵に更新してくださいって話だよ
>Heartbleedバグはクライアント側でも発症するバグだから
クライアント側でどのようなバグが発症するの？
具体的にどうぞ

660 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 06:57:59.11 ID:HzuQuOzg
>>655 (略)
> クライアント側でどのようなバグが発症するの？
指摘されてんだからちゃんと調べてから反論しろよアホ。サーバ側で起きるのと全く同じ現象が起きる。
Heartbleedは細工されたHeartbeatメッセージを受けとったOpenSSLライブラリが隠しておくべきデータを返すバグ。
Heartbeatはサーバクライアント双方が送信できるメッセージだからクライアント側のデータもしっかりと盗まれる。
攻撃側がサーバになるから攻撃サーバに接続させるための攻撃手順が必要になるし、
盗まれうるデータもサーバの場合よりマシな事が多いからあまり言及されていないだけ。(略)

662 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 08:54:33.38 ID:lqcrEoFq
>>660
>クライアント側のデータもしっかりと盗まれる。
だからこれはサーバ側のバグだろうが
メモリの内容を読み取るバグはサーバ側にあったんだよ
悪用すればクライアント側のメモリの内容を引き出すこともできるので
サーバ側のバグを潰したバージョンアップをした上で
バグサーバを悪用できないようにクライアント側の鍵も更新したわけ
>指摘されてんだからちゃんと調べてから反論しろよアホ。
指摘され修正されたのは上記の内容であって
クライアント側のバグなど指摘されていないｗ (略)

664 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 09:28:28.68 ID:HzuQuOzg
(略) >>662
おまえ・・・原理まで説明されてるのに誤解続行とか信じられんレベルで馬鹿だな・・・(略)
http://www.infoq.com/jp/news/2014/04/android_heartbleed
> Googleは先週，Android 4.1.1にOpenSSLのHeartbleedバグが影響することを発表した
> TLS heartbeatには対称性があるため，クライアントとサーバのいずれがエンドポイントである場合にも悪用される可能性がある
http://www.cisco.com/cisco/web/support/JP/112/1122/1122331_cisco-sa-20140409-heartbleed-j.html
> 影響を受けるデバイスは、 SSL コネクションを終端する SSL サーバまたは、SSL コネクションを開始する SSL クライアントです
http://tosebro.hatenablog.com/entry/2014/04/27/013015
> リバースHeartbleedでは「リバース」の名の通り、サーバがクライアントを攻撃するHeartbleedである

675 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 18:32:10.61 ID:7d3dDTJd
>>664
その解説は>>663と同じことを言ってるだけ
サーバのバグでクライアントも影響を受けると書いてあるわけだが
クライアントはサーバ側が境界検査することを前提にしているから
バグを悪用したサーバから不正な要求をされてもそれを防ぐようには作られていないって話

683 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 01:02:29.94 ID:b1Gb7HOS
>>675
つまりサーバに「攻撃用クライアントからの不正な要求を受けた際にメモリを漏らすバグ」があるのと同様に、
クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
言ってることが180度変わってるんだけど頭大丈夫か？

689 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 02:33:13.82 ID:GqSdja6D
>>683
> クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
いやいや全く違う
クライアント側は要求に対して正しく応答しているだけ
サーバ側は攻撃者が正式な鍵を使用せず不正な要求をしてきた場合
接続を維持した状態で要求を無視するのが正しい動作だが、
クライアント側はサーバ側と違い正式な鍵がなければ
攻撃者は接続を維持できないのでサーバ側と同じ動作は本来不要
クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
メールサーバのフィルタリングがぶっ壊れててウイルスを受信してしまっても
メールソフト側にバグがあることにはならないのと似たようなもん

>>86:689
> 正しく応答しているだけ
返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。

> クライアント側はサーバ側と違い正式な鍵がなければ攻撃者は接続を維持できない
正式な鍵(正確には証明書)は必ずしも必要ではないし、正式な証明書を用意できるケースが有る。
攻撃側のサーバは予め提示可能なタイプの証明書を持っていないという応答を返すことも出来るし、
自身の正しい証明書を用意できるサーバを攻撃に使用すれば何の問題もなく攻撃に入ることが出来る。
例えば、広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。

> クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
攻撃を被弾するリスクが減少するだけでバグはバグ。
実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
そもそも、セキュリティを司るモジュールが認証済みの相手ならば攻撃されても良いなんてポリシーなわけがない。

いい加減あきらめろよ

701 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 22:57:35.98 ID:AXin1lzd
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。

良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している

>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。

サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない

>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。

サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない

701 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 22:57:35.98 ID:AXin1lzd
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。

良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している

>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。

サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない

>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。

サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない

>>88
> サーバ側のバグを悪用して
だからサーバもクライアントもどちらでも起きるバグだって何回言えば分かるんだよ
> 想定されていないし想定するのはおかしい
Webブラウザはセキュリティを意識する必要はないとでも言いたげだな
> サーバ側のバグがなければ不可能
クライアントにも全く同じバグが有るんだから不可能
> しかもWebブラウザとSimejiは関係ない
おまえがソース見れるから全部のバグやバックドア見つけれるなんて超アホなこと言い出したから、
ソースを何十何百と言う人間が見れたにも関わらず年単位で放置されたバグの例を教えただけだよ
> メールサーバがフィルタするはずのウイルスを送ってくるバグ
ちげぇよ。
サーバを相手に攻撃を仕掛けるのはクライアントとして振る舞う攻撃用プログラムで、本来想定されるクライアント用プログラムではないし、
クライアントを相手に攻撃を仕掛けるのはサーバとして振る舞う攻撃用プログラムで、本来想定されるサーバ用プログラムではない。
相手が正しいサーバかどうかをチェックする為のプログラムが、不正なサーバ相手にメモリお漏らしなんて許されるわけねーだろアホ

オープンソースのレビューは
だれも確認してなくても時間が経過すると
OKみたいな不思議な仕組み

不思議でもなんでもない
人的リソースはどこも慢性的に不足してるから
あるかどうかもわからない確認待っていれば何も進まない

この問題、組み込み機器とかの問題もあるしまったく解決してないよね

>>93
古いやつは下手するとサポート切れ扱いで放置(→新しい製品に買い替えろ)なんてことになるのだろうね…。