@kazuho なるほど、たしかにそれでだいぶ絞り込めますね。次は時間軸(スナップショット)での確率と帯域とRTTの問題かなぁ。
2014-04-11 13:00:06@n_soda @kazuho たしかにログに残らないというのは大きいですね。64bitだとmallocで確保されるアドレスがランダムかつ広範囲なので探しにくいとかありましたっけ?
2014-04-11 13:01:58@kenn 「漏れてるかもしれないんで、パスワード変えときました」、って言われたらめんどくさくてキレるでしょw
2014-04-11 13:03:52@kenn 斜め読みしたので間違っている可能性がありますが 64kb ずつ何回も任意の場所を読めるのでなかったでしたっけ?間違っていたらごめんなさい?
2014-04-11 13:05:17@higepon 読めるみたいですね。なので64kbのスナップショット中に認証情報が存在する確率pと、バレない程度に送り続けるスループットtを掛け算して、かつ64kbをスキャンして発掘する計算量Oが、辞書攻撃など他の代替手段とくらべてどのぐらいのコストか、ですよね。
2014-04-11 13:07:40@kenn はいその通りだと思います。痕跡が残らないのでたとえ確率が低くても対処した方が良いという結論なんでしょうね。
2014-04-11 13:09:25@kenn んー、数が多ければともかく、少なけば分かりにくい気がしますが。セッション貼りっぱなしは例外として。まぁどちらにせよ。今までに何があったか判断しようがない。攻撃されていたかも分からないので、安全確保という意味以上は無さそうですが。
2014-04-11 13:10:58@higepon 痕跡は、帯域の使用量という形で残ります。メモリ内容をWAN転送するわけなので、非常に高コストではあるはずです。ページあたりの存在確率次第ではありますが。
2014-04-11 13:11:08実際、一般的なサービスで64kbのスナップショットに認証情報が含まれる確率pがどのぐらいなのか?に尽きるな。0.1と0.001と0.00001とでは全然違ってくる。メモリのダンプをWAN転送するのは超ノイジーというのがぼくの感覚なのだけど。
2014-04-11 13:21:32@kenn @kazuho 64bit OSでASLRが効いてれば、たしかに探しにくいでしょうね。攻撃受けてサーバプロセスがcrash頻発している状況だと特に32bit OSでは要注意かと。あとASLRない古いOSも。
2014-04-11 13:28:02@mattn_jp えーと、その情報がその64kbのアドレス空間の範囲内に配置されてる確率を100%にできるという根拠は?という質問なのですが。。。
2014-04-11 13:30:36@mattn_jp 問題にしているのは、漏れてるかどうかではなくて(漏れてるのは確定事項)、その情報にいきあたる統計的な確率です。確実にペイロードを取得できる固定されたアドレスが存在したということ?
2014-04-11 13:34:53@kenn 最初に理屈がよくわからないと言われていますが、その後のやりとりではリスク自体は(コストが高い割に効率が悪いと考えられているが)わかっているので、理屈がよくわからないと言ってしまうのは語弊があるか言葉足らずではないかと思いました。
2014-04-11 13:41:31@kenn このサイト、固定の payload を送ってそのメモリが見れるかのテストをやってるんですが対処前は何度やっても見れてましたね。 http://t.co/ckX6tzzRQq
2014-04-11 13:46:45@mattn_jp @kenn それは送ったペイロードがでてくるまでリピートするからで、それにかかるコストの話をしてる。
2014-04-11 13:50:52@kamipo 取得できるのは狙ったユーザじゃなくランダムなユーザの情報ってのがポイントで、代替手段である辞書攻撃などとくらべてコストがどうか、が争点であるはずですよね。パスワードの変更を気軽に要求しすぎ(=ユーザへの責任転嫁)、というのがぼくの印象です。
2014-04-11 13:55:54