IntelのHTTに深刻な脆弱性
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2005/05/14(土) 13:32:27http://www.itmedia.co.jp/enterprise/articles/0505/14/news009.html
0002名無しさん＠お腹いっぱい。
2005/05/14(土) 13:41:190003名無しさん＠お腹いっぱい。
2005/05/14(土) 13:49:160004名無しさん＠お腹いっぱい。
2005/05/14(土) 13:54:150005名無しさん＠お腹いっぱい。
2005/05/14(土) 14:02:24local information leakだし、低〜中程度の脅威。
「深刻」ってのはハードウェアの設計を根本的に見直さないと対策が難しいからか。
0006名無しさん＠お腹いっぱい。
2005/05/14(土) 14:45:34そのうち各 OS ベンダーからパッチが出て終わりなんじゃないの?
0007名無しさん＠お腹いっぱい。
2005/05/14(土) 14:49:110008名無しさん＠お腹いっぱい。
2005/05/14(土) 15:50:530009名無しさん＠お腹いっぱい。
2005/05/14(土) 19:22:480010名無しさん＠お腹いっぱい。
2005/05/14(土) 19:42:140011名無しさん＠お腹いっぱい。
2005/05/14(土) 20:38:47AMDサーバ買おうとしてる奴にとって上司を説得するネタにはなる。
0012名無しさん＠お腹いっぱい。
2005/05/14(土) 20:47:450013名無しさん＠お腹いっぱい。
NGNG0014名無しさん＠お腹いっぱい。
2005/05/14(土) 21:02:30http://groups.google.co.jp/group/sci.crypt/browse_thread/thread/fdfdcff637cc21f4/b60b10c13f809d9c?hl=ja
http://groups.google.co.jp/group/fa.linux.kernel/browse_thread/thread/6de219af720cddfc/04e19756a1267c66?hl=ja
0015名無しさん＠お腹いっぱい。
2005/05/14(土) 21:03:080016名無しさん＠お腹いっぱい。
2005/05/14(土) 22:27:10Colinはそう言ってるけど、Intelは仕様だって言うんじゃないかと思う。
投機スレッドをHTTで動かしてメモリレイテンシを削減する技術の提案とかしてるし。
やっぱスケジューラががんばって洩れても平気なスレッド同士しか同じコアに
割り振らないようにするしかないんじゃないかな。
0017名無しさん＠お腹いっぱい。
2005/05/15(日) 00:06:480018名無しさん＠お腹いっぱい。
2005/05/15(日) 02:01:530019名無しさん＠お腹いっぱい。
2005/05/15(日) 03:10:180020名無しさん＠お腹いっぱい。
2005/05/15(日) 19:05:55CPUでも全く同じ問題があるでしょ。個人的感想は>>5と同じ。
>>7
OpenBSDは対策とるつもりがないみたいだから、もしもこの件を
重視するならFreeBSDの方が安全だよ。
どうでもいいけど、HTTに直接対応してなくても影響を受ける
のに、そのことを理解してないような文面なのもなんだかなと
思った。
0021名無しさん＠お腹いっぱい。
2005/05/17(火) 01:14:140022名無しさん＠お腹いっぱい。
2005/05/17(火) 10:19:350023名無しさん＠お腹いっぱい。
2005/05/17(火) 11:16:24どのOSが安全とかじゃなくてさっさとHTToffにして再起動しろと。
0024名無しさん＠お腹いっぱい。
2005/05/17(火) 11:20:22ttp://lists.freebsd.org/pipermail/freebsd-security/2005-May/002917.html
で書いてるように、Colinの提案どおり同一プロセス内のスレッドのみを割り
振るようにするのがパフォーマンス的にも好ましい対策。
FreeBSDではまずULEスケジューラをちゃんとしないといけないけど。。。
0025名無しさん＠お腹いっぱい。
2005/05/17(火) 11:44:18全体としたらやはりパフォーマンスを落す結果になりそうだが。
0026名無しさん＠お腹いっぱい。
2005/05/17(火) 18:53:27書いてもいいよね？ (´A｀)ﾏﾝﾄﾞｸｾ
0027名無しさん＠お腹いっぱい。
2005/05/18(水) 10:20:36Hyper-Threadingの脆弱性 - そのメカニズムとは?
0028名無しさん＠お腹いっぱい。
2005/05/18(水) 12:20:59マルチユーザで使ってるような場合には問題になることもあるかもしれないけど。
0029名無しさん＠お腹いっぱい。
2005/05/18(水) 13:03:080030名無しさん＠お腹いっぱい。
2005/05/18(水) 13:19:330031名無しさん＠お腹いっぱい。
2005/05/18(水) 18:30:22wwwwwwwwwwwwwwwwwwwwっウェwwwwwwwwwwwwwwwっウェwwwwwｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0032名無しさん＠お腹いっぱい。
2005/05/18(水) 20:43:540033名無しさん＠お腹いっぱい。
2005/05/18(水) 23:19:38バカバカしい。その時にhyper threadingで同時に実行されている
相手が何をしているか知る手段が提示されていない。
0034名無しさん＠お腹いっぱい。
2005/05/18(水) 23:39:030035名無しさん＠お腹いっぱい。
2005/05/18(水) 23:45:41最初の段落に論文へのリンクがはってあるよ
0036名無しさん＠お腹いっぱい。
2005/05/19(木) 00:04:17憶測しようにもなにがなんやら分からんのでは？
0037きじゃくせいについて
2005/05/19(木) 00:59:380038名無しさん＠お腹いっぱい。
2005/05/19(木) 01:20:54きじゃくせい？
0039名無しさん＠お腹いっぱい。
2005/05/19(木) 01:40:060040名無しさん＠お腹いっぱい。
2005/05/19(木) 02:59:15アクセスできないはずだというのをまず大前提としているんだけど、
HTT の問題ではこの前提が成り立たなくなっちゃう。
なので、いろんなセキュリティ機構が役に立たなくなる(HTT の問題を
悪用すると抜け道が作れてしまう)のでやばい、ってところだね。
0041名無しさん＠お腹いっぱい。
2005/05/19(木) 06:13:38……まあ、論文を読んでみなさい。
0042名無しさん＠お腹いっぱい。
2005/05/19(木) 07:50:12説明してやればいいのに。
0043名無しさん＠お腹いっぱい。
2005/05/19(木) 07:56:03これ読めばいいじゃん。
0044名無しさん＠お腹いっぱい。
2005/05/19(木) 13:13:50AMD信者のデマだよもん
0045名無しさん＠お腹いっぱい。
2005/05/19(木) 13:36:45HTであってもアクセスはできない。
応答時間で当たり外れを推測するもの。
推測が当たるも外れるも運次第だ。
0046名無しさん＠お腹いっぱい。
2005/05/19(木) 13:40:43「誰かがアクセスしたはずである」というのを脆弱性と呼ぶのか？
HTを脆弱というならDNSのキャッシュも脆弱だと言ってくれ。
串サーバーのキャッシュも脆弱だと言ってくれ。
そもろもDNSもHTも串も誰がキャッシュに残したのか？はそもそも不明。
0047名無しさん＠お腹いっぱい。
2005/05/19(木) 13:59:01( ﾟ,_ゝﾟ)ﾊﾞｶｼﾞｬﾈｰﾉ
0048名無しさん＠お腹いっぱい。
2005/05/19(木) 14:22:58じゃなくて、暗号を復号する時の具体的なアルゴリズム、
場合によってはバイナリプログラムが特定されていて、
別スレッドが今どんなオペレーションを実行しているかが推測できれば
アルゴリズム上の実行パスを推測することができて、
それを暗号を推測するために使うことができる、ということでしょ。
例えば、ここで3回連続多倍長の乗算をしているから、この条件分岐は
true側だったはずなんで、じゃあこのビットは1のはずだろう、とか。
0049名無しさん＠お腹いっぱい。
2005/05/19(木) 19:46:41そこまでまったく意味が分かってないのによくレスする気になったもんだｗ
0050名無しさん＠お腹いっぱい。
2005/05/19(木) 19:55:090051名無しさん＠お腹いっぱい。
2005/05/19(木) 20:26:190052名無しさん＠お腹いっぱい。
2005/05/19(木) 20:33:59財布にいれずにジーパンのポケットに突っ込んでおくと
割れて使い物にならなくなる.
0053名無しさん＠お腹いっぱい。
2005/05/19(木) 20:36:580054名無しさん＠お腹いっぱい。
2005/05/19(木) 21:32:190055名無しさん＠お腹いっぱい。
2005/05/19(木) 21:34:360056名無しさん＠お腹いっぱい。
2005/05/19(木) 22:00:55それ以前に、つづりが違うだろ。
cash card
http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%82%AB%E3%83%BC%E3%83%89
cache
http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%29
0057名無しさん＠お腹いっぱい。
2005/05/19(木) 22:02:24それ、ただの閉め忘れだろ。
0058名無しさん＠お腹いっぱい。
2005/05/19(木) 22:14:510059名無しさん＠お腹いっぱい。
2005/05/19(木) 22:15:350060名無しさん＠お腹いっぱい。
2005/05/19(木) 22:18:100061名無しさん＠お腹いっぱい。
2005/05/19(木) 22:44:14ジーパンにかぎんねぇだろ?
ズボンについてるジッパーの危険性に大差はないと思うぞ,
急いでるときは特に...
0062名無しさん＠お腹いっぱい。
2005/05/19(木) 22:51:430063名無しさん＠お腹いっぱい。
2005/05/19(木) 23:06:21SMPだとどのプロセッサーでスレッドが走るかを予測することも指定することもできない。
マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
キケンな環境でHT使っている香具師はとっととBIOSの設定を変えるべし。
SMP用のカーネルだけを入れている人は大変かも？
0064名無しさん＠お腹いっぱい。
2005/05/19(木) 23:12:180065名無しさん＠お腹いっぱい。
2005/05/19(木) 23:48:17> マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
2nd cache 共有のタイプだと, cache の構成によっては似たような事は
可能だと思われる.
0066名無しさん＠お腹いっぱい。
2005/05/19(木) 23:54:41ここの説明が判りやすいかも。
ttp://w3.quake3.jp/sushi-k/index.php?itemid=321
■ このスレッドは過去ログ倉庫に格納されています