2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

OpenSSLの重大なバグって

1 :仕様書無しさん:2014/04/08(火) 22:52:56.23
いくらお前らでも対策できないよな

2 :仕様書無しさん:2014/04/08(火) 23:07:00.99
 ̄ ̄ ̄ ̄ ̄ ̄ ̄l/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ∧_∧
         ( ´・ω・`)     ∧_∧
         /     \   (    )何言ってんだこいつ
     .__| |    .| |_ /      ヽ
     ||\  ̄ ̄ ̄ ̄   / .|   | |
     ||\..∧_∧    (⌒\|__./ ./
     ||.  (    )     ~\_____ノ|   ∧_∧
       /   ヽ 空気読めよ   \|   (    ) 
       |     ヽ           \/     ヽ. オマエ馬鹿だろ
       |    |ヽ、二⌒)        / .|   | |
       .|    ヽ \∧_∧    (⌒\|__./ /

3 :仕様書無しさん:2014/04/08(火) 23:07:17.71
1.0.1なんて新しいバージョン使ってないし

4 :仕様書無しさん:2014/04/09(水) 01:07:30.38
影響あるのはフリーソフト使ってる奴らだけだろ?
プロプライエタリな俺らには関係ないよ

5 :仕様書無しさん:2014/04/09(水) 01:18:18.83
アプリケーションサーバのSSL実装独自でやってるところあるんだ

6 :仕様書無しさん:2014/04/09(水) 01:22:19.19
Openと名前のつくものは関わらないほうがいい

7 :仕様書無しさん:2014/04/09(水) 01:51:12.27
オープン系(死語)

8 :仕様書無しさん:2014/04/09(水) 22:41:14.91
いや、今まさに対応してきたんだが

9 :仕様書無しさん:2014/04/10(木) 04:44:36.27
>>6
Open XMLフォーマットを採用してるMS Office使えないじゃん

10 :仕様書無しさん:2014/04/11(金) 01:43:51.84
Open XMLフォーマットを使わなければよい

11 :仕様書無しさん:2014/04/11(金) 03:24:51.20
>>10
でもソフトがOpen XMLに対応している

12 :仕様書無しさん:2014/04/11(金) 18:35:00.89
OpenSSLの脆弱性を含んだライブラリーを使った市販の製品もあるから、
クライアント側では、それらも対策しないといけないな。

13 :仕様書無しさん:2014/04/12(土) 07:38:09.78
Windows Server無双

14 :仕様書無しさん:2014/04/12(土) 13:40:21.26
【ネット】暗号化ソフト欠陥、NSAは2年前から認識−情報収集に利用
http://ai.2ch.net/test/read.cgi/newsplus/1397276668/

15 :仕様書無しさん:2014/04/12(土) 16:08:49.06
>>1
いくらってww
もともとレゴブロックのように部品をくっつけるしかできないやつが99%だよww
部品開発すら出来ない連中なんだからww

16 :仕様書無しさん:2014/04/12(土) 16:27:21.96
Open-GLはいずこへ。

17 :仕様書無しさん:2014/04/12(土) 18:06:36.61
OpenGL ESなら普通にスマートフォンで使われてるらしい

18 :仕様書無しさん:2014/04/16(水) 21:38:06.54
>>1
ハートビート機構のところの
サイズチェックとメモリの確保のところをいじるだけだぞ・・・・

19 :仕様書無しさん:2014/04/18(金) 01:55:49.18
>>5
普通RSAから買うだろ。

20 :仕様書無しさん:2014/04/19(土) 09:34:47.11
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 :仕様書無しさん:2014/04/19(土) 21:02:21.40
結局、自分が対象になってるかはどうやって確認したらいいの?
それとどういう対策が必要?

22 :仕様書無しさん:2014/04/19(土) 21:12:16.72
>>21
確認方法は、opensslのバージョンを確認すること。
主要なディストリならもう更新が来てるはず。パッケージ更新しておけば大丈夫だろ。

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

24 :仕様書無しさん:2014/04/22(火) 19:08:28.42
>>23
これつかって他所のサイトを調べたら攻撃と見なされて逮捕とかならないの?

25 :仕様書無しさん:2014/04/23(水) 00:34:06.99
>>23
HeartBleedな

26 :仕様書無しさん:2014/04/23(水) 00:38:29.87
いやこの場合はビードで合ってるだろ。頭悪いのか?

27 :仕様書無しさん:2014/04/23(水) 00:39:51.06
HeartBleedが意図した動作しちゃダメだろ

28 :仕様書無しさん:2014/04/23(水) 00:47:45.91
これがマ板のレベルですよ皆さんw

29 :仕様書無しさん:2014/04/23(水) 00:57:58.44
一昨日のWBSで簡単な説明があったな。
クラッカー側が、セッションを始める時点でのやりとりを利用してるとか。

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

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

30 :仕様書無しさん:2014/04/23(水) 01:26:16.34
>>29
簡単に言うと、OpenSSL 1.0.1 で搭載された生存監視 (Heart Beat = 心臓の鼓動確認) のバグ。

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

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

31 :仕様書無しさん:2014/04/23(水) 01:28:01.87
こんなもんよく今まで誰も気付かなかったなとそちらに驚く

32 :仕様書無しさん:2014/04/23(水) 02:23:12.47
OpenSSLの脆弱性の露呈で、沢山の目にソースが見られているから欠陥がすぐ
わかる、問題は修正される、だから安全というオープンソース安全神話は完全に崩れたよな。

33 :仕様書無しさん:2014/04/23(水) 04:08:39.61
>>30
すげーわかりやすいな
多分ドキュメント作るセンスあるな

34 :仕様書無しさん:2014/04/23(水) 08:11:57.92
>>24
どうだろうな…まったく問題ないという自信はない。もともと
https://filippo.io/Heartbleed/
このサイトの検知サービスのコードで、外部に公開してない
サーバーを調べるのに自分は使った。

35 :仕様書無しさん:2014/04/23(水) 11:41:43.84
>>28
偏差値45くらいだろプログラマの平均偏差値ってw

36 :仕様書無しさん:2014/04/23(水) 11:44:12.74
>>33
どこがだ?
ここはプログラマ板だぞ。
はしょったプログラムのせれば十分だろ

37 :仕様書無しさん:2014/04/23(水) 13:00:28.47
>>35
偏差値ではかれない能力を持ってるのが俺らだろ

38 :仕様書無しさん:2014/04/23(水) 15:59:37.16
>>36
いや、俺は上手い文章だと思うけど。
お客への説明に使えるし
マ板だからって全部プログラムで
書く必要も無いんじゃね?

39 :仕様書無しさん:2014/04/24(木) 01:02:39.13
>>38
とてもわかりやすいよな
これにケチつけるひねくれた性格が、この業界に性格の腐った奴が多いと思われる原因

40 :仕様書無しさん:2014/04/24(木) 21:51:18.47
>>38
いや、うまい文章のまえに、ソースみてみろ。そのままだから。
ソース見たほうが圧倒的に早い。

41 :仕様書無しさん:2014/04/25(金) 01:27:43.62
>>40
いや、本人が自画自賛してるだけだから。

42 :仕様書無しさん:2014/04/25(金) 04:17:48.28
ソース見たら分かるというのは詭弁

43 :仕様書無しさん:2014/04/25(金) 04:21:02.34
オープンソースが安全っていう神話は崩れたな

44 :仕様書無しさん:2014/04/25(金) 06:42:23.07
本当のことじゃないから神話なんじゃないの?

45 :仕様書無しさん:2014/04/25(金) 08:27:03.63
いつまでも古いシステムを人が変わってまでサポートし続けるくらいなら
新しく作りなおしたほうがいいわ

46 :仕様書無しさん:2014/04/25(金) 09:33:00.92
クローズドソースのほうが安全ですという奴は一生WinXP使ってろ

47 :仕様書無しさん:2014/04/25(金) 10:21:12.44
>>46
最新のWindowsはオープンソースなのか?

48 :仕様書無しさん:2014/04/25(金) 10:55:22.73
論理学的には最新のWindowsがオープンソースだろうがなかろうが
WinXPの安全性の真偽の命題には関係ないね。はい次の人どうぞ。

49 :仕様書無しさん:2014/04/25(金) 11:36:20.55
>>48
なんでXPを推すの?

50 :仕様書無しさん:2014/04/25(金) 14:20:25.54
XPとだけ比べて欲しいから。
XPとなら勝てる(それ以降では負ける)と
思っているから。

51 :仕様書無しさん:2014/04/25(金) 15:00:20.33
クローズドソースなら安心という人はXPなんとかして下さいよ

52 :仕様書無しさん:2014/04/25(金) 15:02:30.36
何とかする=新しいOSにアップグレードする。

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

53 :仕様書無しさん:2014/04/25(金) 15:51:56.04
やはり最強は北朝鮮が制作したRedStarLinuxだな

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

55 :仕様書無しさん:2014/04/25(金) 21:08:34.26
オープンだろうがクローズだろうが
規模が大きくなれば同じ事。

56 :仕様書無しさん:2014/04/26(土) 03:17:33.58
>>51
バカなの?それとも詭弁を弄してるつもりなの?

57 :仕様書無しさん:2014/04/26(土) 23:05:13.41
OpenSSLプロジェクトはお金と人を入れられるようでなにより
http://www.atmarkit.co.jp/ait/articles/1404/25/news150.html

58 :仕様書無しさん:2014/04/27(日) 05:41:42.00
俺33だが30とは赤の他人だぞ

59 :仕様書無しさん:2014/04/27(日) 10:36:43.97
やっぱオープンソースって開発元がまともにテストしてないし
利用者側もまともにテストしない

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

60 :仕様書無しさん:2014/04/27(日) 12:50:29.96
ドッグフードを食べるって知っているか?

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

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

62 :仕様書無しさん:2014/04/27(日) 20:37:20.96
ドッグフードの話ってのはテストの有効性というより、もっと精神論的な、
自分で使えないようなものは本当に力を入れては作らない(だから使うべきだ)
ということじゃないの?

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

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

63 :仕様書無しさん:2014/04/27(日) 21:31:06.42
>>60
テストが万能じゃないからって、テストを放棄していいわけじゃない
そして>>59はオープンソースはドッグフードを食べてないって話をしてるんだよ
そもそもドッグフードを食べる話だってWindowsの事じゃないか

64 :仕様書無しさん:2014/04/27(日) 22:04:15.83
不具合なんかテストで見つけるもんであって
ソース読んで探すものじゃないからな

65 :仕様書無しさん:2014/04/27(日) 22:47:25.39
その後見つかった不具合は
ソース読んで直すんだからな。

66 :仕様書無しさん:2014/04/27(日) 22:48:10.95
脆弱性(不具合)を見つけるとき
ハッカーはソース読むんだからな。

67 :仕様書無しさん:2014/04/27(日) 22:50:49.33
おまえら何の話してんの?

68 :仕様書無しさん:2014/04/29(火) 00:07:37.48
お前ら、ドッグフードにソースかけて食うのか?

69 :仕様書無しさん:2014/04/29(火) 00:38:45.54
おまえらが食ってるのはタコの足だよ

70 :仕様書無しさん:2014/05/14(水) 10:02:20.24
>>25
heartbeatな

71 :仕様書無しさん:2014/05/14(水) 14:51:38.72
どんなに時が早く過ぎてもふたりだけはこのままでいようと誓った

72 :仕様書無しさん:2014/05/16(金) 20:21:26.85
>>32
そんなものはとっくの昔に無いと思う。

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

73 :仕様書無しさん:2014/05/20(火) 20:36:56.03
>>72
> >>32
> そんなものはとっくの昔に無いと思う。

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

74 :仕様書無しさん:2014/05/24(土) 18:45:46.04
しかしきたねーわかりにくいソースだなぁ

75 :仕様書無しさん:2014/05/25(日) 21:58:14.01
だかそれがいい。

76 :仕様書無しさん:2014/06/06(金) 21:02:51.94
また脆弱性きたです

77 :仕様書無しさん:2014/06/07(土) 00:04:51.95
うわー月曜行きたくねえ。

78 :仕様書無しさん:2014/06/17(火) 09:19:15.39
果たしてTheoは救世主となるか?

79 :仕様書無しさん:2014/06/17(火) 09:48:36.39
TheOpenSSL 2.0まだー?

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

81 :仕様書無しさん:2014/06/30(月) 02:08:21.43
>>80
それは君の能力が足りないだけでは。

82 :仕様書無しさん:2014/06/30(月) 02:31:43.98
>>81
違うよ

83 :仕様書無しさん:2014/06/30(月) 02:56:52.79
>>82
やっぱり能力不足だ(確信)

84 :仕様書無しさん:2014/06/30(月) 03:00:32.80
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はサーバクライアント双方が送信できるメッセージだからクライアント側のデータもしっかりと盗まれる。
攻撃側がサーバになるから攻撃サーバに接続させるための攻撃手順が必要になるし、
盗まれうるデータもサーバの場合よりマシな事が多いからあまり言及されていないだけ。(略)

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

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と同じことを言ってるだけ
サーバのバグでクライアントも影響を受けると書いてあるわけだが
クライアントはサーバ側が境界検査することを前提にしているから
バグを悪用したサーバから不正な要求をされてもそれを防ぐようには作られていないって話

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

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

87 :仕様書無しさん:2014/06/30(月) 03:20:02.24
>>86:689
> 正しく応答しているだけ
返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。

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

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

いい加減あきらめろよ

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

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

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

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

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

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

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

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

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

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

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

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

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

91 :仕様書無しさん:2014/07/05(土) 08:26:44.87
オープンソースのレビューは
だれも確認してなくても時間が経過すると
OKみたいな不思議な仕組み

92 :仕様書無しさん:2014/07/05(土) 14:44:58.39
不思議でもなんでもない
人的リソースはどこも慢性的に不足してるから
あるかどうかもわからない確認待っていれば何も進まない

93 :仕様書無しさん:2014/09/23(火) 21:38:17.44
この問題、組み込み機器とかの問題もあるしまったく解決してないよね

94 :仕様書無しさん:2014/09/23(火) 21:56:44.89
>>93
古いやつは下手するとサポート切れ扱いで放置(→新しい製品に買い替えろ)なんてことになるのだろうね…。

95 :仕様書無しさん:2016/07/30(土) 21:14:46.65
大阪府三島郡島本町は暴力とイジメの
暴力とイジメのブラックタウンなの?

28 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)