【セキュリティ】Intelのハイパースレッディングに深刻な脆弱性
知ってるらしいな、さすがだね関係者
シングルユーザなら問題ない、って意見あるけど、
HT上で動いているスパイウェアがキャッシュを監視して、
パスワードを抜き出す、ってことは技術的に可能?
>>125 そんなもんHTTバグなんかつかなくてもできることじゃんw
127 :
125:2005/05/15(日) 18:24:10 ID:???
>>126 そうなんだけど。
技術的な可能性を知りたかっただけで・・・
>>127 HTとは無関係に可能
というかシングルユーザや普段使っているアカウントにroot権限なり
管理者権限がある場合は、この件とは無関係に他プロセスのデータを
盗めるんだから、そういう意味で問題ないといっているのにすぎない。
>>125のような人にはどう説明したら良いんだろうね。
>>128のように説明されてもなんとなく騙されたような感じになってるんじゃなかろうか?
同じような質問やたら多いし。
130 :
名無しさん@お腹いっぱい。:2005/05/16(月) 04:25:24 ID:gjnFuRUB
つーかOS側で対応すればモウマンタイ。
そもそもスレッド制御はOSでやってるはずだから、
OSにもHTTに対する不備があったと考えるべき。
もっさりCPUイラネ
>129
ちょっと乱暴だけど、
「今回のHTTの脆弱性は、物理的に違うコア(ということになっている)で走っているスレッドが
現在進行形で処理しているデータを生で覗き見出来る可能性が発生したのが問題なのであって、
以下>128」
って感じに説明すれば解り易いかと。
もう一歩噛み砕いて喩えるなら、電話からの情報漏洩。
従来の脆弱制は、電話器周辺(root権限)から精々がクロージャー辺りに盗聴器(spyware)が仕掛けられていた程度。
今回のは電話局の交換機にバイパス仕掛ける方法(HTTの仕様と今回のコード)が晒された、と。
勿論、設置・実現難度は後者の方が圧倒的に高いが、って感じに。
キャッシュの中身のデータそのものまで見えるの?
それだとヤバすぎだけど、そうじゃない気がする。
GNUのCVSサーバの ssh鍵が漏れて大騒ぎになったことがあったなぁ。
あのときはえらい労力かけてチェックして改変されたソースは無かったってことだったけど。
そんな感じで便利なフローソフトに開発者も知らない間にスパイコードが埋め込まれて、、、、
だれも知らない間にとんでもない被害が出そう。
その程度ならまだマシで、openssh自体の鯖がクラックされたことあったでしょ。
あの事件では、配布しているopensshのアーカイブに改変が見つかったと記憶しているが。
世界最速、Mac。
顧客の満足度もナンバーワン。
Macはハードが気にいらない。
今の自作PCにMacOSが乗るようになったら考えてもいい。
深刻な脆弱性って言うけど、こんなのでカギを盗む努力をするのなら
普通にクラックした方がずっと楽じゃねーか?理論が実証されたのは確か
だろうけど、正直、これを使ってクラックするなんて手間暇かける奴が
いるとは思えない。
>>135 ソースコードチェックでひっかかるのならまだマシ。コンパイラに
バックドアを仕込まれたら、いくらソースをチェックしても分からない。
メーカーに対する顧客満足度なのだから
ナンバーワンが
アップル。
1024bitの合成数をまともに素因数分解せよと?
>>139 マルチユーザー環境のPCでこっそり情報を抜きたいときは便利っぽい。
クラックした形跡も残らないしな。
世界最速、Mac。
顧客の満足度もナンバーワン。
┏━━━━━━━┓
┃ 日 マ ┃
┃ 本 ッ ま┃
┃マ 語 ク あ┃
┃ッ は の 縦┃
┃ク 縦 速 書┃
┃世 書 さ き┃
┃界 き が し┃
┃最 際 て┃
┃速 立 み┃
┃ つ ろ┃
┗━━━━━━━┛
顧客満足度トップって言っても、Mac買ってるのってもともとMacテイストに満足してるやつばっかだろ?
だから、顧客満足度じゃなくて信者満足度というのが正しい。信者なんだ
から満足するのが当然w
そういうこと。
縦書きなんとかって、Macって標準が等幅フォントなの?
一般のPCユーザーへの影響はほとんどあり得ない
ところで、この脆弱性は一般のPCユーザーに何らかの影響を与えるだろうか?
結論から言うと、ほとんど何の影響もないと考えて構わない。
この脆弱性を利用して攻撃するためには、キャッシュのアクセス速度の変化を解析する
コードを侵入させる必要があるが、一般にPC(一人で使うパーソナルコンピュータ)が
侵入を受ける場合、使用者のユーザーアカウントが乗っ取られるのが普通だ。
使用者のユーザーアカウントなら、使用者の持つ情報のすべてが取得できるので、
何もキャッシュを覗き見るような面倒な手法を使う必要はないのである。
http://pcweb.mycom.co.jp/articles/2005/05/17/ht/002.html
>>133 1つのCPU内部で併走するプロセス同士で、互いの情報を盗むことができる……
といっても、ここまでの解説で分かるように、
データが直接に覗き見れるわけではない。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
キャッシュのアクセス速度のパターン変化から「併走するプロセスが
何をやっているのか推定できる程度」の情報しか得られないと言っていい。
だが管理されているマルチユーザー環境のPCにはかなり痛い欠陥
相変わらずなぜか必死なやつがいるが、
一般ユーザーとか推定できる程度とか
セキュリティーの上では関係ない
脆弱性があることが問題
M社のトラックに欠陥があって、それを放置していた
その部品は一部乗用車にも使われていたが
乗用車ではかかる荷重が違うので問題ない
でも、こんなメーカーの車を社会は容認できない
>>139 SSLキー盗み出しプログラムコードが論文と一緒に出ちゃってるんだからSSL KEYロガーができちゃう。
クライアントにはキーロガー、HTのサーバにはSSLキーロガーっていうのが定番になるんじゃねーの?
こんなの日本製品で出たら、
日本のマスコミは大騒ぎだろ。
やっぱり欧米のマスコミって、節度があるな。
>>150が本当なら、DRM抜きにはちょっと役に立たないな…(´・ω・`)ショボーン
ま、MYCOMはインテル提灯持ちがひどいし、わざとミスリードする方向で記事書いてる可能性も。
この脆弱性の本質(?)は、アルゴリズムやプログラムが十分既知であれば、
キャッシュアクセスパターンからその内容が分かるような気がする、というものだよね?
例えていうならば、夜寝てたら、薄い壁をはさんだアパートの隣の
部屋からあえぎ声が聞こえてきて興奮したみたいな。でも実は単なる
AVビデオだったかもしれんので、バカみたい。
というところか。
でもキャッシュアクセスが実行ごとにランダムになるような
アルゴリズムにすれば防げるのでは?
RDTSC命令の使用を禁止するだけ
DMAの度にTLB参照したくないからでそ
AMDはFSB統合したからそこらへんの実装は楽そう
どうなんでしょうね。
実際にかなりやばい事なんだろうか?
それとも実際に事件がおこってからでないと気がつかないのか?
>>139はコンパイラにもソースコードがあるのを知らないんでしょうか
>>163 ヒント:
UNIX誕生から数十年たったとき作者が明かした有名なエピソード
「そういえば、彼(たぶんリッチー)は今どうやってログインしたんだ?」
>>165 ACMの記事を読みなおしたほうがいいよ。
>>166 実は元の原稿は知らないんで
代わりに解説してくらはい。m(__)m
>>139は「The moral is obvious. You can't trust code that you did not totally create yourself.」の意味がわからないのでしょうか?
略してハイスレ
>>171 実際にそういうふうに略す香具師が漏れの周りには複数いる事実