OpenSSLの重大なバグって
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はサーバクライアント双方が送信できるメッセージだからクライアント側のデータもしっかりと盗まれる。
攻撃側がサーバになるから攻撃サーバに接続させるための攻撃手順が必要になるし、
盗まれうるデータもサーバの場合よりマシな事が多いからあまり言及されていないだけ。(略)
(略)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と同じことを言ってるだけ
サーバのバグでクライアントも影響を受けると書いてあるわけだが
クライアントはサーバ側が境界検査することを前提にしているから
バグを悪用したサーバから不正な要求をされてもそれを防ぐようには作られていないって話
>>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
> クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
いやいや全く違う
クライアント側は要求に対して正しく応答しているだけ
サーバ側は攻撃者が正式な鍵を使用せず不正な要求をしてきた場合
接続を維持した状態で要求を無視するのが正しい動作だが、
クライアント側はサーバ側と違い正式な鍵がなければ
攻撃者は接続を維持できないのでサーバ側と同じ動作は本来不要
クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
メールサーバのフィルタリングがぶっ壊れててウイルスを受信してしまっても
メールソフト側にバグがあることにはならないのと似たようなもん
>>675
つまりサーバに「攻撃用クライアントからの不正な要求を受けた際にメモリを漏らすバグ」があるのと同様に、
クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
言ってることが180度変わってるんだけど頭大丈夫か？
689 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 02:33:13.82 ID:GqSdja6D
>>683
> クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
いやいや全く違う
クライアント側は要求に対して正しく応答しているだけ
サーバ側は攻撃者が正式な鍵を使用せず不正な要求をしてきた場合
接続を維持した状態で要求を無視するのが正しい動作だが、
クライアント側はサーバ側と違い正式な鍵がなければ
攻撃者は接続を維持できないのでサーバ側と同じ動作は本来不要
クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
メールサーバのフィルタリングがぶっ壊れててウイルスを受信してしまっても
メールソフト側にバグがあることにはならないのと似たようなもん
>>86:689
> 正しく応答しているだけ
返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
> クライアント側はサーバ側と違い正式な鍵がなければ攻撃者は接続を維持できない
正式な鍵(正確には証明書)は必ずしも必要ではないし、正式な証明書を用意できるケースが有る。
攻撃側のサーバは予め提示可能なタイプの証明書を持っていないという応答を返すことも出来るし、
自身の正しい証明書を用意できるサーバを攻撃に使用すれば何の問題もなく攻撃に入ることが出来る。
例えば、広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
> クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
攻撃を被弾するリスクが減少するだけでバグはバグ。
実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
そもそも、セキュリティを司るモジュールが認証済みの相手ならば攻撃されても良いなんてポリシーなわけがない。
いい加減あきらめろよ
> 正しく応答しているだけ
返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
> クライアント側はサーバ側と違い正式な鍵がなければ攻撃者は接続を維持できない
正式な鍵(正確には証明書)は必ずしも必要ではないし、正式な証明書を用意できるケースが有る。
攻撃側のサーバは予め提示可能なタイプの証明書を持っていないという応答を返すことも出来るし、
自身の正しい証明書を用意できるサーバを攻撃に使用すれば何の問題もなく攻撃に入ることが出来る。
例えば、広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
> クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
攻撃を被弾するリスクが減少するだけでバグはバグ。
実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
そもそも、セキュリティを司るモジュールが認証済みの相手ならば攻撃されても良いなんてポリシーなわけがない。
いい加減あきらめろよ
701 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 22:57:35.98 ID:AXin1lzd
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している
>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない
>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない
>>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を使うソフトウェアもアップデートを行った。
サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している
>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない
>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない
>>88
> サーバ側のバグを悪用して
だからサーバもクライアントもどちらでも起きるバグだって何回言えば分かるんだよ
> 想定されていないし想定するのはおかしい
Webブラウザはセキュリティを意識する必要はないとでも言いたげだな
> サーバ側のバグがなければ不可能
クライアントにも全く同じバグが有るんだから不可能
> しかもWebブラウザとSimejiは関係ない
おまえがソース見れるから全部のバグやバックドア見つけれるなんて超アホなこと言い出したから、
ソースを何十何百と言う人間が見れたにも関わらず年単位で放置されたバグの例を教えただけだよ
> メールサーバがフィルタするはずのウイルスを送ってくるバグ
ちげぇよ。
サーバを相手に攻撃を仕掛けるのはクライアントとして振る舞う攻撃用プログラムで、本来想定されるクライアント用プログラムではないし、
クライアントを相手に攻撃を仕掛けるのはサーバとして振る舞う攻撃用プログラムで、本来想定されるサーバ用プログラムではない。
相手が正しいサーバかどうかをチェックする為のプログラムが、不正なサーバ相手にメモリお漏らしなんて許されるわけねーだろアホ
> サーバ側のバグを悪用して
だからサーバもクライアントもどちらでも起きるバグだって何回言えば分かるんだよ
> 想定されていないし想定するのはおかしい
Webブラウザはセキュリティを意識する必要はないとでも言いたげだな
> サーバ側のバグがなければ不可能
クライアントにも全く同じバグが有るんだから不可能
> しかもWebブラウザとSimejiは関係ない
おまえがソース見れるから全部のバグやバックドア見つけれるなんて超アホなこと言い出したから、
ソースを何十何百と言う人間が見れたにも関わらず年単位で放置されたバグの例を教えただけだよ
> メールサーバがフィルタするはずのウイルスを送ってくるバグ
ちげぇよ。
サーバを相手に攻撃を仕掛けるのはクライアントとして振る舞う攻撃用プログラムで、本来想定されるクライアント用プログラムではないし、
クライアントを相手に攻撃を仕掛けるのはサーバとして振る舞う攻撃用プログラムで、本来想定されるサーバ用プログラムではない。
相手が正しいサーバかどうかをチェックする為のプログラムが、不正なサーバ相手にメモリお漏らしなんて許されるわけねーだろアホ
オープンソースのレビューは
だれも確認してなくても時間が経過すると
OKみたいな不思議な仕組み
だれも確認してなくても時間が経過すると
OKみたいな不思議な仕組み
92 ：仕様書無しさん：2014/07/05(土) 14:44:58.39
不思議でもなんでもない
人的リソースはどこも慢性的に不足してるから
あるかどうかもわからない確認待っていれば何も進まない
人的リソースはどこも慢性的に不足してるから
あるかどうかもわからない確認待っていれば何も進まない
この問題、組み込み機器とかの問題もあるしまったく解決してないよね
>>93
古いやつは下手するとサポート切れ扱いで放置(→新しい製品に買い替えろ)なんてことになるのだろうね…。
古いやつは下手するとサポート切れ扱いで放置(→新しい製品に買い替えろ)なんてことになるのだろうね…。