Heartbleed脆弱性の影響とパスワード変更に関する議論

22
Kazuho Oku @kazuho

@kenn 毎回ランダムなアドレスにバッファが確保されるという前提がそもそもおかしいかと

2014-04-11 12:56:33
Kazuho Oku @kazuho

リバースプロキシとか、いかにバッファを使い回すかが、パフォーマンスの重要な要素なんですよ

2014-04-11 12:58:41
Kenn Ejima @kenn

@kazuho なるほど、たしかにそれでだいぶ絞り込めますね。次は時間軸(スナップショット)での確率と帯域とRTTの問題かなぁ。

2014-04-11 13:00:06
d6rkaiz @d6rkaiz

@kenn カフェとかの公衆無線LANのある環境でならどうですかね?

2014-04-11 13:01:49
Kenn Ejima @kenn

@n_soda @kazuho たしかにログに残らないというのは大きいですね。64bitだとmallocで確保されるアドレスがランダムかつ広範囲なので探しにくいとかありましたっけ?

2014-04-11 13:01:58
Tatsuhiko Miyagawa @miyagawa

@kenn 「漏れてるかもしれないんで、パスワード変えときました」、って言われたらめんどくさくてキレるでしょw

2014-04-11 13:03:52
Kenn Ejima @kenn

@d6rkaiz いや、サーバ側での帯域の使用料だよ。たいていモニターしてるよね。

2014-04-11 13:03:55
Kenn Ejima @kenn

@miyagawa うん、そっちは確実にキレるね。w

2014-04-11 13:04:47
Taro Minowa Higepon @higepon

@kenn 斜め読みしたので間違っている可能性がありますが 64kb ずつ何回も任意の場所を読めるのでなかったでしたっけ?間違っていたらごめんなさい?

2014-04-11 13:05:17
Kenn Ejima @kenn

@higepon 読めるみたいですね。なので64kbのスナップショット中に認証情報が存在する確率pと、バレない程度に送り続けるスループットtを掛け算して、かつ64kbをスキャンして発掘する計算量Oが、辞書攻撃など他の代替手段とくらべてどのぐらいのコストか、ですよね。

2014-04-11 13:07:40
Taro Minowa Higepon @higepon

@kenn はいその通りだと思います。痕跡が残らないのでたとえ確率が低くても対処した方が良いという結論なんでしょうね。

2014-04-11 13:09:25
d6rkaiz @d6rkaiz

@kenn んー、数が多ければともかく、少なけば分かりにくい気がしますが。セッション貼りっぱなしは例外として。まぁどちらにせよ。今までに何があったか判断しようがない。攻撃されていたかも分からないので、安全確保という意味以上は無さそうですが。

2014-04-11 13:10:58
Kenn Ejima @kenn

@higepon 痕跡は、帯域の使用量という形で残ります。メモリ内容をWAN転送するわけなので、非常に高コストではあるはずです。ページあたりの存在確率次第ではありますが。

2014-04-11 13:11:08
Kenn Ejima @kenn

実際、一般的なサービスで64kbのスナップショットに認証情報が含まれる確率pがどのぐらいなのか?に尽きるな。0.1と0.001と0.00001とでは全然違ってくる。メモリのダンプをWAN転送するのは超ノイジーというのがぼくの感覚なのだけど。

2014-04-11 13:21:32
mattn @mattn_jp

@kenn Basic認証 over SSL で100%

2014-04-11 13:25:10
SODA Noriyuki @n_soda

@kenn @kazuho 64bit OSでASLRが効いてれば、たしかに探しにくいでしょうね。攻撃受けてサーバプロセスがcrash頻発している状況だと特に32bit OSでは要注意かと。あとASLRない古いOSも。

2014-04-11 13:28:02
mattn @mattn_jp

@kenn でなくてもセッショントークンくらいは漏れますよね。でパスワードを勝手に…

2014-04-11 13:29:51
Kenn Ejima @kenn

@mattn_jp えーと、その情報がその64kbのアドレス空間の範囲内に配置されてる確率を100%にできるという根拠は?という質問なのですが。。。

2014-04-11 13:30:36
mattn @mattn_jp

@kenn heroku が対処する前の状態だとリクエストペイロードは漏れてました。

2014-04-11 13:32:21
Kenn Ejima @kenn

@mattn_jp 問題にしているのは、漏れてるかどうかではなくて(漏れてるのは確定事項)、その情報にいきあたる統計的な確率です。確実にペイロードを取得できる固定されたアドレスが存在したということ?

2014-04-11 13:34:53
Ryuta Kamizono @kamipo

@kenn 最初に理屈がよくわからないと言われていますが、その後のやりとりではリスク自体は(コストが高い割に効率が悪いと考えられているが)わかっているので、理屈がよくわからないと言ってしまうのは語弊があるか言葉足らずではないかと思いました。

2014-04-11 13:41:31
mattn @mattn_jp

@kenn このサイト、固定の payload を送ってそのメモリが見れるかのテストをやってるんですが対処前は何度やっても見れてましたね。 http://t.co/ckX6tzzRQq

2014-04-11 13:46:45
Tatsuhiko Miyagawa @miyagawa

@mattn_jp @kenn それは送ったペイロードがでてくるまでリピートするからで、それにかかるコストの話をしてる。

2014-04-11 13:50:52
Kenn Ejima @kenn

@kamipo 取得できるのは狙ったユーザじゃなくランダムなユーザの情報ってのがポイントで、代替手段である辞書攻撃などとくらべてコストがどうか、が争点であるはずですよね。パスワードの変更を気軽に要求しすぎ(=ユーザへの責任転嫁)、というのがぼくの印象です。

2014-04-11 13:55:54