IntelのHTTに深刻な脆弱性

Intelのハイパースレッディングに深刻な脆弱性
http://www.itmedia.co.jp/enterprise/articles/0505/14/news009.html

Intelﾀﾞﾒﾎﾟ…

で、セキュリティアップデートはいつでるんだ？

コリンきゅんがIntelに訴えられて京都府警にタイーホされる展開キボン

つか論文読んだけどすごーく微妙で「強く勧告する」ほどの問題じゃねーな。
local information leakだし、低〜中程度の脅威。
「深刻」ってのはハードウェアの設計を根本的に見直さないと対策が難しいからか。

HTT の脆弱性というか SMT ってそういうものだろ。
そのうち各 OS ベンダーからパッチが出て終わりなんじゃないの?

って、まあ *BSD はパッチでてるけどな

そうね。でもまあCPUの方で対応するのがベストな事案ではあるね。

OSの実装じゃなくてHTTそのものに脆弱性なの？

んだ

セキュリティ上の脅威ってほどでもない問題だけどIntelにとっては脅威だな。
AMDサーバ買おうとしてる奴にとって上司を説得するネタにはなる。

この程度ならカーネル側でなんとでも対応できるだろ。

この程度なら運用でなんとでも対応できるだろ。

関連スレッド
http://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

さりげにSCOとFreeBSDがタッグを組んでるな

>>9
Colinはそう言ってるけど、Intelは仕様だって言うんじゃないかと思う。
投機スレッドをHTTで動かしてメモリレイテンシを削減する技術の提案とかしてるし。

やっぱスケジューラががんばって洩れても平気なスレッド同士しか同じコアに
割り振らないようにするしかないんじゃないかな。

どっちにしろHTTなんて消えてゆくテクノロジなんだから使わないのが一番だろ

セロ林でも大して変わらんな

これからのサーバはPentium Mを使った省電力化がトレンド。

別にHTTに特有の問題じゃなくて、キャッシュ共有型マルチコア
CPUでも全く同じ問題があるでしょ。個人的感想は>>5と同じ。

>>7
OpenBSDは対策とるつもりがないみたいだから、もしもこの件を
重視するならFreeBSDの方が安全だよ。
どうでもいいけど、HTTに直接対応してなくても影響を受ける
のに、そのことを理解してないような文面なのもなんだかなと
思った。

対策も何もFreeBSDはHTTをoffにしてるだけみたいだが。

つーか、対策としてはHTTをOFFにするしかないかと…

そういうことだ。
どのOSが安全とかじゃなくてさっさとHTToffにして再起動しろと。

HTTを無効にしてるのは暫定的な対策だよ。DESが
ttp://lists.freebsd.org/pipermail/freebsd-security/2005-May/002917.html
で書いてるように、Colinの提案どおり同一プロセス内のスレッドのみを割り
振るようにするのがパフォーマンス的にも好ましい対策。
FreeBSDではまずULEスケジューラをちゃんとしないといけないけど。。。

マルチスレッドで組んでるプログラムのピーク値を引き上げる効果はあるだろうが
全体としたらやはりパフォーマンスを落す結果になりそうだが。

>>24
書いてもいいよね？　(´A｀)ﾏﾝﾄﾞｸｾ

http://pcweb.mycom.co.jp/articles/2005/05/17/ht/
Hyper-Threadingの脆弱性 - そのメカニズムとは?

深刻って言うほど深刻でもないような。見知らぬあなたと見知らぬあなたが
マルチユーザで使ってるような場合には問題になることもあるかもしれないけど。

多くのホスティングWebサーバがHTTを使ってる予感

使ってないだろw

ｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗ絵ウェwwwwwwwっウェwwwwwっウェwwwwっウェ
wwwwwwwwwwwwwwwwwwwwっウェwwwwwwwwwwwwwwwっウェwwwwwｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ホスティングしてる客には秘密でHT使ってるに、10000ルピー

>>27
バカバカしい。その時にhyper threadingで同時に実行されている
相手が何をしているか知る手段が提示されていない。

$ ps

>>33
最初の段落に論文へのリンクがはってあるよ

俺これの脅威がさっぱりわからないんだけど、大人数のユーザが同時にいろんなプロセスを実行してたら
憶測しようにもなにがなんやら分からんのでは？

↓ここでTheo君の登場

↑
きじゃくせい？

気弱性について

Unixのたいていのセキュリティ技術は他のプロセスのメモリ空間には
アクセスできないはずだというのをまず大前提としているんだけど、
HTT の問題ではこの前提が成り立たなくなっちゃう。

なので、いろんなセキュリティ機構が役に立たなくなる(HTT の問題を
悪用すると抜け道が作れてしまう)のでやばい、ってところだね。

>>40
……まあ、論文を読んでみなさい。

そんな含みを持ったもったいぶった書き方するくらいなら、
説明してやればいいのに。

>>27
これ読めばいいじゃん。

>>1
AMD信者のデマだよもん

>>40
HTであってもアクセスはできない。
応答時間で当たり外れを推測するもの。
推測が当たるも外れるも運次第だ。

DNSサーバーへの問い合わせでキャッシュに残っていたから
「誰かがアクセスしたはずである」というのを脆弱性と呼ぶのか？
HTを脆弱というならDNSのキャッシュも脆弱だと言ってくれ。
串サーバーのキャッシュも脆弱だと言ってくれ。
そもろもDNSもHTも串も誰がキャッシュに残したのか？はそもそも不明。

>>46
( ﾟ,_ゝﾟ)ﾊﾞｶｼﾞｬﾈｰﾉ

>>46
じゃなくて、暗号を復号する時の具体的なアルゴリズム、
場合によってはバイナリプログラムが特定されていて、
別スレッドが今どんなオペレーションを実行しているかが推測できれば
アルゴリズム上の実行パスを推測することができて、
それを暗号を推測するために使うことができる、ということでしょ。

例えば、ここで3回連続多倍長の乗算をしているから、この条件分岐は
true側だったはずなんで、じゃあこのビットは1のはずだろう、とか。

>>46
そこまでまったく意味が分かってないのによくレスする気になったもんだｗ

キャッシュという言葉だけ理解できたんだろう

キャッシュカードの脆弱性について

>>51
財布にいれずにジーパンのポケットに突っ込んでおくと
割れて使い物にならなくなる.

キャッシュカードはタクティカルベストのハンドグレネードポーチに入れましょう。

ジーパンにセキュリティホールを発見した

サイバーノーパンぶらり戦法で万全

>>51
それ以前に、つづりが違うだろ。

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

>>54
それ、ただの閉め忘れだろ。

queueとcacheはなかなか綴りを覚えられなかった

ジーパンのジッパーには潜在的な危険性があるらしい

ジッパー内に秘密鍵ﾊｹｰﾝしました

>>59
ジーパンにかぎんねぇだろ?
ズボンについてるジッパーの危険性に大差はないと思うぞ,
急いでるときは特に...

雪国だと冬、家に帰ってきてトイレに駆け込んだとき必死だぜ

結局のところ、シングルCPUでシングルコアでHTを使うと危険ということかな？
SMPだとどのプロセッサーでスレッドが走るかを予測することも指定することもできない。
マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
キケンな環境でHT使っている香具師はとっととBIOSの設定を変えるべし。
SMP用のカーネルだけを入れている人は大変かも？

ただちに HTT を無効にすべきというほど危険じゃない

>>63
> マルチコアだとどのコアでスレッドが走るかを予測することも指定するこもできない。
2nd cache 共有のタイプだと, cache の構成によっては似たような事は
可能だと思われる.

悪用するのは大変難しいといいつつも実証コードが出ちゃったのが問題だね。

ここの説明が判りやすいかも。
ttp://w3.quake3.jp/sushi-k/index.php?itemid=321

マルチコアじゃなくても、Opteronみたいに
|メモリ| -- |[L2$]-[コア]| --- |[コア]-[L2$]| -- [メモリ]
みたいな構成でもレイテンシに差が出るよ。
SMTだとL1$を共有してるから精度が高いってだけ。

マルチタスクでマルチユーザーの環境では安全では？

>>68
典型的な例として、複数ユーザを詰め込んだレンタルサーバでやられるとどうなると思う？

この脆弱性を利用して侵入してくる奴がいたらうちで雇う

>>69
どうにもならないでしょ。
今回の発表はOpenSSLの特定のバージョンでRSA署名をし続けた場合の実証
でしかなく、"real-world"での漏洩はまず無理だし。

>>69
より安全性が高まるだけでは？

ようするに、この
"ArchitecutualState"というのが
"ProcessorCore"を共有しているのがまずい??

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


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

OpenSSLがセキュリティ・アップデートで
鎮火?

>>73
>>41

>>71
やっぱりライバル会社の妨害工作か・・・・

リモートからの攻撃ではないから安心とか、実証コードは特定のSSLの
バージョンだけだから安心とか。。。。

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

実証コードを元にSSLキーロガーなるものががアンダーグラウンドで流通し
亜流が増え続けるのは時間の問題。
インターネットカフェに仕込むキーボードロガーのようにお宝に当たれば桶という使い方になる。
SSL以外にも順次適用拡大していくんだろうね。
実はレンタルサーバにはあちこち入りはじめているんじゃねーの？
と思ったら深刻な脆弱性という評価になるわけだが。

４ビットや８ビットのマイコンのプログラミングの経験があれば想像できる。
条件が真か偽かでステップ数が異なると処理時間が違ってくるんです。
だからNOPを入れて実ステップ数（時間）を合わせるんです。
特定の演算ユニットがBUSYでもBUSYでなくても処理時間が同じになれば
いいんですよ。
つまり。。。

ここまで読んだ。

唯一残念なのは、このスレで参考になった物が一つもなかった事だ。

>>78は全く参考にならんな。

>>80 も全くｓｙんづお
Stack overflow

Z80のリフレッシュレジスタを掴んでたまにスタックオーバフロー起こさせて連荘させるパチンコのあれか？
よしOpenSSLの次バージョンはそれでいこうじゃないか。（Z80限定サポート）

INVD (0F08)
flush internal caches; initiate flushing of external caches.
...
The INVD instruction is a privilieged
...

というのをカーネルモードでやると
どうでsか?　却下?

>>69
同時に動いているプロセス/スレッドがSSLだけという条件が必要だろ。
つまり、全然現実的じゃない。例えば一緒にapacheでも動かして
トラフィックかかってればレイテンシのパターンは読めなくなる。

>>83
そうとも言えないんじゃないかな。
強い局所性でサイドチャネルにエラー(誤情報)が載るか、
それとも対象プロセスの局所性をマスクするほど大量の負荷が同時に
かかっていないと、多少帯域幅は落ちてもサイドチャネル自体は
生きているように思える。

しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、
対象プロセスの全ての動作タイミングでサイドチャネルをマスクできる
アクティビティがかかることを保証しないといけない。

>>84
> しかもモニタするプロセスは条件に合うタイミングを気長に待てばよく、

そのタイミングをどうやって知るの？キャッシュのページエラーを起こしているのが
SSLの秘密鍵処理であってapacheによるIOに絡んだキャッシュ消費やJavaVMに
よる巨大ヒープへのアクセスによるものじゃないことが、どうやってわかる？
ユーザーランドで得られる情報じゃ粒度が全然合わないと思うけど・・・

知る必要があるの?
エラーが入ってたら捨てて次回を待てばいいのでは?

>>86
> エラーが入ってたら捨てて次回を待てばいいのでは?

エラーかどうかをどう判定する？
観測できるのは各命令のレイテンシーだけだよ。
そのレイテンシーがもう1つの仮想プロセッサで実行されている
SSLのコードの特定のスレッドの影響であることをどうやって知ることができる？

>>87
もう一度だけヒント。知る必要あるの?

エラーを別のものと勘違いしてるもより

>>85の言うエラー（ページエラー、キャッシュミス。
そもそもこれがあるかないかで1bitの情報を得る）と
>>86の言う「エラー」の意味が食い違っていると思う

>>86に質問
盗聴プロセスを走らせて、「011000100010100」というbit列を手に入れたとき
それがOpenSSLの秘密鍵の部分情報なのか、apacheプロセスのディスクIOに
よるものなのか、どうやって判定すればいいの？

>>88
あのー、君、盗聴の方法をちゃんと理解してる？

そういえばキーボードロガーのキーストローク記録からキャッシュカード番号の入力を特定するってどうやってるんだろ。

キャッシュカードの番号と一緒に名前とか入れるだろうから、
その前後にあるそれらしい数字を探せば特定できるじゃん。

インテル最悪ッｽ

このスレに限って「鼬買い」とか言われないのはどうしてですか?

UNIX板は雑談スレ建て放題ですから

そう。夜11時から朝8時までは、スレ建て放題

...こんなでうごくだろうか?
とりあえずｺﾝﾊﾟﾙしてみよう。

--- 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

なんかものすごく板違いされた悪寒

そう？いいんじゃないここで

えー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 <-- 注目!!

...しつれいしますた。巣に帰ります。

てゆーか、単に表示を変更しても意味ないような。。。

実際の被害報告ってあります？

てゆーか、お前FreeBSDのパッチ読んでないだろ……

>>96-97 いや、建て放題でも鼬買いは鼬買いと言われるでしょう。
最近は自治厨がいなくなったのかな。

全然よくわからないんだけど、
セグメンテーションでは防げないのか？＞メモリアクセス

ユーザプロセスがLDTを自由に作成できるなら話は別だけど
普通はメモリのアクセス範囲って決まってるものじゃないの？

全然深刻だと思えない。

実際のシステムではノイズが大きすぎて実用にはならないな。

論文読んでみて、
- cache miss を使った covert channel の構築するという発想
- それを実際に実現したプログラミング力
- ルーチンパターンから鍵を推定する数学力
に、ただただ感心した。コリンきゅんすげー、自分とおないどしなことに orz

エマさーーーーーーーん