トップページ⇒unix
110コメント31KB

IntelのHTTに深刻な脆弱性

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2005/05/14(土) 13:32:27
Intelのハイパースレッディングに深刻な脆弱性
http://www.itmedia.co.jp/enterprise/articles/0505/14/news009.html
0060名無しさん＠お腹いっぱい。2005/05/19(木) 22:18:10
ジッパー内に秘密鍵ﾊｹｰﾝしました
0061名無しさん＠お腹いっぱい。2005/05/19(木) 22:44:14
>>59
ジーパンにかぎんねぇだろ?
ズボンについてるジッパーの危険性に大差はないと思うぞ,
急いでるときは特に...
0062名無しさん＠お腹いっぱい。2005/05/19(木) 22:51:43
雪国だと冬、家に帰ってきてトイレに駆け込んだとき必死だぜ
0063名無しさん＠お腹いっぱい。2005/05/19(木) 23:06:21
結局のところ、シングルCPUでシングルコアでHTを使うと危険ということかな？
SMPだとどのプロセッサーでスレッドが走るかを予測することも指定することもできない。
マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
キケンな環境でHT使っている香具師はとっととBIOSの設定を変えるべし。
SMP用のカーネルだけを入れている人は大変かも？
0064名無しさん＠お腹いっぱい。2005/05/19(木) 23:12:18
ただちに HTT を無効にすべきというほど危険じゃない
0065名無しさん＠お腹いっぱい。2005/05/19(木) 23:48:17
>>63
> マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
2nd cache 共有のタイプだと, cache の構成によっては似たような事は
可能だと思われる.
0066名無しさん＠お腹いっぱい。2005/05/19(木) 23:54:41
悪用するのは大変難しいといいつつも実証コードが出ちゃったのが問題だね。

ここの説明が判りやすいかも。
ttp://w3.quake3.jp/sushi-k/index.php?itemid=321
0067名無しさん＠お腹いっぱい。2005/05/19(木) 23:57:40
マルチコアじゃなくても、Opteronみたいに
|メモリ| -- |[L2$]-[コア]| --- |[コア]-[L2$]| -- [メモリ]
みたいな構成でもレイテンシに差が出るよ。
SMTだとL1$を共有してるから精度が高いってだけ。
0068名無しさん＠お腹いっぱい。2005/05/20(金) 00:08:07
マルチタスクでマルチユーザーの環境では安全では？
0069名無しさん＠お腹いっぱい。2005/05/20(金) 00:42:12
>>68
典型的な例として、複数ユーザを詰め込んだレンタルサーバでやられるとどうなると思う？
0070名無しさん＠お腹いっぱい。2005/05/20(金) 00:59:46
この脆弱性を利用して侵入してくる奴がいたらうちで雇う
0071名無しさん＠お腹いっぱい。2005/05/20(金) 01:00:04
>>69
どうにもならないでしょ。
今回の発表はOpenSSLの特定のバージョンでRSA署名をし続けた場合の実証
でしかなく、"real-world"での漏洩はまず無理だし。
0072名無しさん＠お腹いっぱい。2005/05/20(金) 01:34:02
>>69
より安全性が高まるだけでは？
0073名無しさん＠お腹いっぱい。2005/05/20(金) 03:45:50
ようするに、この
"ArchitecutualState"というのが
"ProcessorCore"を共有しているのがまずい??

ttp://www.fbmnd.fh-frankfurt.de/~doeben/II-INF3/II-INF3-TH/VL12/intel-hyperthreading-700.jpg


>>66
>プロセスのキャッシュのアクセス速度の変化パターンから鍵を類推

OpenSSLがセキュリティ・アップデートで
鎮火?
0074名無しさん＠お腹いっぱい。2005/05/20(金) 05:02:57
>>73
>>41
0075名無しさん＠お腹いっぱい。2005/05/20(金) 07:02:52
>>71
やっぱりライバル会社の妨害工作か・・・・
0076名無しさん＠お腹いっぱい。2005/05/20(金) 09:24:09
リモートからの攻撃ではないから安心とか、実証コードは特定のSSLの
バージョンだけだから安心とか。。。。

Theoと喧嘩になるような人ばかりですね。

実証コードを元にSSLキーロガーなるものががアンダーグラウンドで流通し
亜流が増え続けるのは時間の問題。
インターネットカフェに仕込むキーボードロガーのようにお宝に当たれば桶という使い方になる。
SSL以外にも順次適用拡大していくんだろうね。
実はレンタルサーバにはあちこち入りはじめているんじゃねーの？
と思ったら深刻な脆弱性という評価になるわけだが。
0077名無しさん＠お腹いっぱい。2005/05/20(金) 10:27:53
４ビットや８ビットのマイコンのプログラミングの経験があれば想像できる。
条件が真か偽かでステップ数が異なると処理時間が違ってくるんです。
だからNOPを入れて実ステップ数（時間）を合わせるんです。
特定の演算ユニットがBUSYでもBUSYでなくても処理時間が同じになれば
いいんですよ。
つまり。。。

0078名無しさん＠お腹いっぱい。2005/05/20(金) 14:05:21
ここまで読んだ。

唯一残念なのは、このスレで参考になった物が一つもなかった事だ。
0079名無しさん＠お腹いっぱい。2005/05/20(金) 14:13:25
>>78は全く参考にならんな。
0080名無しさん＠お腹いっぱい。2005/05/20(金) 15:40:30
>>80 も全くｓｙんづお
Stack overflow
0081名無しさん＠お腹いっぱい。2005/05/20(金) 23:43:20
Z80のリフレッシュレジスタを掴んでたまにスタックオーバフロー起こさせて連荘させるパチンコのあれか？
よしOpenSSLの次バージョンはそれでいこうじゃないか。（Z80限定サポート）
0082名無しさん＠お腹いっぱい。2005/05/21(土) 13:46:27
INVD (0F08)
flush internal caches; initiate flushing of external caches.
...
The INVD instruction is a privilieged
...

というのをカーネルモードでやると
どうでsか?　却下?
0083名無しさん＠お腹いっぱい。2005/05/21(土) 13:54:21
>>69
同時に動いているプロセス/スレッドがSSLだけという条件が必要だろ。
つまり、全然現実的じゃない。例えば一緒にapacheでも動かして
トラフィックかかってればレイテンシのパターンは読めなくなる。
0084名無しさん＠お腹いっぱい。2005/05/21(土) 14:50:31
>>83
そうとも言えないんじゃないかな。
強い局所性でサイドチャネルにエラー(誤情報)が載るか、
それとも対象プロセスの局所性をマスクするほど大量の負荷が同時に
かかっていないと、多少帯域幅は落ちてもサイドチャネル自体は
生きているように思える。

しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、
対象プロセスの全ての動作タイミングでサイドチャネルをマスクできる
アクティビティがかかることを保証しないといけない。
0085名無しさん＠お腹いっぱい。2005/05/21(土) 14:56:27
>>84
> しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、

そのタイミングをどうやって知るの？キャッシュのページエラーを起こしているのが
SSLの秘密鍵処理であってapacheによるIOに絡んだキャッシュ消費やJavaVMに
よる巨大ヒープへのアクセスによるものじゃないことが、どうやってわかる？
ユーザーランドで得られる情報じゃ粒度が全然合わないと思うけど・・・
0086名無しさん＠お腹いっぱい。2005/05/21(土) 15:01:10
知る必要があるの?
エラーが入ってたら捨てて次回を待てばいいのでは?
0087名無しさん＠お腹いっぱい。2005/05/21(土) 16:22:31
>>86
> エラーが入ってたら捨てて次回を待てばいいのでは?

エラーかどうかをどう判定する？
観測できるのは各命令のレイテンシーだけだよ。
そのレイテンシーがもう1つの仮想プロセッサで実行されている
SSLのコードの特定のスレッドの影響であることをどうやって知ることができる？
0088名無しさん＠お腹いっぱい。2005/05/21(土) 17:01:21
>>87
もう一度だけヒント。知る必要あるの?


0089名無しさん＠お腹いっぱい。2005/05/21(土) 17:08:56
エラーを別のものと勘違いしてるもより
0090名無しさん＠お腹いっぱい。2005/05/22(日) 00:21:28
>>85の言うエラー（ページエラー、キャッシュミス。
そもそもこれがあるかないかで1bitの情報を得る）と
>>86の言う「エラー」の意味が食い違っていると思う

>>86に質問
盗聴プロセスを走らせて、「011000100010100」というbit列を手に入れたとき
それがOpenSSLの秘密鍵の部分情報なのか、apacheプロセスのディスクIOに
よるものなのか、どうやって判定すればいいの？
0091名無しさん＠お腹いっぱい。2005/05/22(日) 03:45:51
>>88
あのー、君、盗聴の方法をちゃんと理解してる？
0092名無しさん＠お腹いっぱい。2005/05/22(日) 03:59:48
そういえばキーボードロガーのキーストローク記録からキャッシュカード番号の入力を特定するってどうやってるんだろ。
0093名無しさん＠お腹いっぱい。2005/05/22(日) 16:11:16
キャッシュカードの番号と一緒に名前とか入れるだろうから、
その前後にあるそれらしい数字を探せば特定できるじゃん。
0094名無しさん＠お腹いっぱい。2005/05/22(日) 18:23:45
インテル最悪ッｽ
0095名無しさん＠お腹いっぱい。2005/05/22(日) 19:35:41
このスレに限って「鼬買い」とか言われないのはどうしてですか?
0096名無しさん＠お腹いっぱい。2005/05/22(日) 21:00:39
UNIX板は雑談スレ建て放題ですから
0097名無しさん＠お腹いっぱい。2005/05/22(日) 21:15:49
そう。夜11時から朝8時までは、スレ建て放題
0098名無しさん＠お腹いっぱい。2005/05/22(日) 22:47:01
...こんなでうごくだろうか?
とりあえずｺﾝﾊﾟﾙしてみよう。

--- kernel-source-2.6.11/arch/i386/kernel/cpu/common.c 2005-03-02 16:37:47.000000000 +0900
+++ kernel-source-2.6.11.hoge/arch/i386/kernel/cpu/common.c 2005-05-22 22:38:12.374133296 +0900
@@ -446,13 +446,16 @@

if (!cpu_has(c, X86_FEATURE_HT))
return;
-
+#if 0
cpuid(1, &eax, &ebx, &ecx, &edx);
smp_num_siblings = (ebx & 0xff0000) >> 16;

if (smp_num_siblings == 1) {
printk(KERN_INFO "CPU: Hyper-Threading is disabled\n");
} else if (smp_num_siblings > 1 ) {
+#endif /* 0 */
+ smp_num_siblings = 2;
+
index_lsb = 0;
index_msb = 31;

@@ -477,7 +480,9 @@

printk(KERN_INFO "CPU: Physical Processor ID: %d\n",
phys_proc_id[cpu]);
+#if 0
}
+#endif /* 0 */
}
#endif
0099名無しさん＠お腹いっぱい。2005/05/22(日) 23:09:37
なんかものすごく板違いされた悪寒
0100名無しさん＠お腹いっぱい。2005/05/22(日) 23:29:27
そう？いいんじゃないここで
0101名無しさん＠お腹いっぱい。2005/05/23(月) 00:12:00
えーt、戻り値をつかっているので、cpuid()は実行しないとだめの、もよう。

Linux version 2.6.11 (root@orz) (gcc バージョン 3.3.6 (Debian 1:3.3.6-5)) #1 SMP Sun May 22
23:06:58 JST 2005
...
Kernel command line: BOOT_IMAGE=orz ro root=302 acpismp=force
...
Initializing CPU#0
...
CPU0: Intel(R) Pentium(R) 4 CPU 2.53GHz stepping 07
per-CPU timeslice cutoff: 1463.07 usecs.
task migration cache decay timeout: 2 msecs.
Total of 1 processors activated (5013.50 BogoMIPS).
WARNING: 1 siblings found for CPU0, should be 2

警告された...しかし!!

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.53GHz
stepping : 7
cpu MHz : 2533.874
cache size : 512 KB
physical id : 0
siblings : 2 <-- 注目!!

...しつれいしますた。巣に帰ります。
0102名無しさん＠お腹いっぱい。2005/05/23(月) 02:15:30
てゆーか、単に表示を変更しても意味ないような。。。
0103名無しさん＠お腹いっぱい。2005/05/23(月) 10:27:52
実際の被害報告ってあります？
0104名無しさん＠お腹いっぱい。2005/05/23(月) 10:39:49
てゆーか、お前FreeBSDのパッチ読んでないだろ……
0105952005/05/24(火) 23:06:22
>>96-97 いや、建て放題でも鼬買いは鼬買いと言われるでしょう。
最近は自治厨がいなくなったのかな。
0106名無しさん＠お腹いっぱい。2005/05/26(木) 09:49:23
0107名無しさん＠お腹いっぱい。2005/06/07(火) 20:56:07
全然よくわからないんだけど、
セグメンテーションでは防げないのか？＞メモリアクセス

ユーザプロセスがLDTを自由に作成できるなら話は別だけど
普通はメモリのアクセス範囲って決まってるものじゃないの？
0108名無しさん＠お腹いっぱい。2005/06/08(水) 06:57:11
全然深刻だと思えない。
0109名無しさん＠お腹いっぱい。2005/07/17(日) 08:52:19
実際のシステムではノイズが大きすぎて実用にはならないな。

論文読んでみて、
- cache miss を使った covert channel の構築するという発想
- それを実際に実現したプログラミング力
- ルーチンパターンから鍵を推定する数学力
に、ただただ感心した。コリンきゅんすげー、自分とおないどしなことに orz
0110名無しさん＠お腹いっぱい。2005/07/18(月) 08:17:53
エマさーーーーーーーん
■ このスレッドは過去ログ倉庫に格納されています