多くのDDR3モジュールで記録データを簡単に破壊させられる脆弱性が発見される 38
ストーリー by hylom
ソフト的に攻撃できるのね 部門より
ソフト的に攻撃できるのね 部門より
あるAnonymous Coward 曰く、
カーネギーメロン大学とインテル・ラボの報告によると、多くのDDR3メモリモジュールで記録内容を破壊できる脆弱性が発見されたようだ。特定の制御線に予定外の電圧変動が起こると、隣接した制御線にエラーが起きるというものらしい(論文PDF:Flipping Bits in Memory Without Accessing Them:An Experimental Study of DRAM Disturbance Errors、Slashdot)。
この問題は短いループ内で特定のオフセットに対しメモリ読みだしを発生させる操作とキャッシュ制御命令を実行するだけで、簡単に発生させられるという。大手DRAMメーカー129製品をテストしたところ、110の製品でこの問題が発生したという。具体的な攻撃内容については説明されていないが、Using Memory Errors to Attack a Virtual Machine(論文PDF)のような手法を使って仮想マシンのサンドボックス上から攻撃を行うといった可能性がある模様。
既知の問題 (スコア:5, 興味深い)
デバイス製造側からすると既知の問題ですね。
DRAMを微細化していくと隣接セルへの干渉が増えるのは、ずっと前から(10年以上前から)指摘されています。
そのせいで、30nmが限界だとか、20nmが限界だとか言われながら、微細化を続けてきました。
これをどの程度押さえるかはコストと信頼性のトレードオフであり、ゼロにはできません。
必要な信頼性はECCで確保する、今後はCRCやもっと複雑なエラー訂正を導入しようって方向です。
NANDは既に素子単体での信頼性確保は不可能で、エラー訂正含めて信頼性を議論していますが、DRAMもその後を追うだけかと思います。
Re:既知の問題 (スコア:2, 興味深い)
ディスターブの問題なんて10年以上前どころか30年以上前からですがな
通常のプログラムではありえないような厳しいアクセスパターンで不良が生じる、あえて厳しいテストパターンを用いてスクリーニングするのはDRAMでは常識です
そういう嫌らしい(?)テストパターンを作るのが得意な(?)お客さんがいて、クレームで次々選別テストパターンを追加していくとテストタイムが足りなくなってくる......
Re:既知の問題 (スコア:1)
30年前とすると、多分それは別の問題です。以下のコメント参照。
http://security.srad.jp/comments.pl?sid=648375&cid=2734556 [srad.jp]
隣接するラインへのRead回数で問題が起きることは2000年台には聞いたと思いますが、30年前はさすがにない。
Re:既知の問題 (スコア:1)
Re: (スコア:0)
せめてパリティでもつけますか。
90年頃の256k/1Mbit DRAMのSIMMとかは、チップ9個着いてるのが普通だった。
Re: (スコア:0)
リフレッシュ変動の問題もあるので、そろそろECC内蔵になるかも。
カスタムDRAMでは既に実績あるし。
#設計は大変になるけど
Re:既知の問題 (スコア:1)
ECCをDRAMチップ内に内蔵するのと、隣接ラインのアクセス数を監視してリフレッシュ制御を行う方法が今のところ有力です。
×破壊させられる ○破壊できる (スコア:1)
×多くのDDR3モジュールで記録データを簡単に破壊させられる脆弱性が発見される
○多くのDDR3モジュールで記録データを簡単に破壊できる脆弱性が発見される
補完すると「ある人がシステムにデータを破壊させられる」のつもりで書いたのだろうけれど、
文法上「システム」に行為を強制しているのか、「ある人」に行為を強制しているのか分からない。
しかも、補完すると「に」がダブる。
Re: (スコア:0)
君の頭の中には○か☓しか無いのか
意図せずこの攻撃を起こしてしまう (スコア:1)
ことってないんですか?
Re:意図せずこの攻撃を起こしてしまう (スコア:1)
連続アクセスにはふつーcacheが効くので現実には怒らない。
でFA?
非リニア化 (スコア:0)
対症療法としては
RAMなんだから物理アドレスをスクランブルすればよいとは思うが
そのコストが(非常に)問題だなぁ。ソフトじゃ無理だなぁ
(仮想アドレッシングで逃げられるほどの粒度ならあるいは)
既存のハードでは対処のしようが無いし
新しいチップセットにはこの対策が含まれるようになるのだろうか。
しかし、メモリメーカでもあらかじめわかると思うんだけど
東芝FDD訴訟みたいに欠陥だとして訴えられたらwktk
Re:非リニア化 (スコア:1)
RAMなんかのセル配置は二次元に並んでいますが
実際には、レイアウト上の都合や色々な最適化の結果、
仕様書上のアドレス端子をリニアにX-Yに振ったセル配置にはなりません
なので、CPUからリニアにアクセスしても隣接セルが連続でアクセスされる保証はないです
もちろん、データ線に関しても同様で、同一アドレスのD0、D1が隣接するセルとは限りません
さらに、小容量メモリを除くと、スペアブロックとの置換処理(救済処理)なんかも入りますので、さらに・・・
ちなみに、製造過程のテストではそれらの内部設計仕様書使って、物理的に隣接したセルを意識したテストをします
>東芝FDD訴訟みたいに欠陥だとして訴えられたらwktk
仕様書と異なる動作なら、不良、もしくは欠陥
仕様外の条件で発生しているのであれば、使用上の問題ですね
Re: (スコア:0)
具体的な対策は
A.これを発表した研究者の元に行き、具体的詳細を聞いてその研究者に多額の研究費を寄付し研究させ、出てきた情報を弁護士に多額の費用を払って賠償請求訴訟を起こして世間に問題を喚起、悪辣非道の手抜きメーカに正義の鉄拳を喰らわせると共に、問題の製品を回収させるか、緩和対策をメーカの責任でさせる事で、世界の平和を守る正義のヒーローになる。
B.よくこんなのはっけんしたね!すごいね! さすが!って感嘆し、あくようされたらこわいね、こわいね!って震えるなど、スラドで馬鹿話をした後、飯を食って風呂入ってアイス食ってクソして寝る
このどちらかかな
Re: (スコア:0)
風呂でうんこすんな
Re: (スコア:0)
その2択なら絶対Bだろ。
何択だろうがAは絶対選ばれることのない、いわば選択肢もどきだから。
Re: (スコア:0)
WindowsならEMET [microsoft.com]で撃墜できんかな
クロストーク (スコア:0)
への対策をちゃんとしてなかった、ということ?
Re:クロストーク (スコア:5, 参考になる)
セルのリークが増えるという現象です.リークに対してリフレッシュが
追い付かないとデータが壊れてしまいます.また,新規の脆弱性(?)ではなく,
昔から知られている現象を広汎に調べてみたというものです.でもデータ量は
圧倒的で,よくここまでたくさん(120モジュール以上も)調べたな,と圧倒されました.
なお「特定の制御線に予定外の電圧変動が起こる」というとなんだか大変なことを
しないとだめそうに読めますが,やっていることは,キャッシュが効かない状態
で隣接ワードへの連続アクセスをするだけです.ふつうはキャッシュが効く状態で
使ってますから問題ないです.
攻撃手段としてみると,自プロセス以外のページ割り当てがどうなっているかは
分からないし,狙ったビットをフリップさせられるわけでもないので,効率の悪い
DOS攻撃くらいにしか使えないように思います.
Re: (スコア:0)
しかし、サンドボックス内からこんな事ができる可能性があるのはビックリ。
砂場は荒すためにある (スコア:0)
問題は外まで砂が漏れちゃうケースでしょ。
※JAVAとかFlash Playerではよくあること
Re: (スコア:0)
この方式だと漏れ無くても攻撃できるのではないのですか。
Re:インテル・ラボ (スコア:0)
一方で、インテルはメインストリームのCPUはECC非対応にしちゃいましたが…
ソフトエラーも微細化で影響が懸念されてましたよね?
Re: (スコア:0)
対策そのものはしてると思うけど、ここまで微細化が進むとゆとりがないのも事実。
これ、同様の事がNAND-Flashで起きないか誰か検証してないのかなあ?
桅弱性発見した! (スコア:0, おもしろおかしい)
多くのメモリモジュールはライトイネーブル信号に電圧変動が起きると記録内容が改ざんされてしまう
Re: (スコア:0)
き…桅弱性
#実際何と入力して変換したのか
Re: (スコア:0)
書いて認識かもしれん。
JIT型のインタプリタからの任意のコード実行 (スコア:0)
JIT型のインタプリタなら、何度もコードを実行しながら、命令キャッシュを破棄すればこの攻撃が成立する。
命令長が可変長のものなら、それを使って命令長を変え、後続する命令を変えることができ、更には任意のコードの実行が可能になる。
ただ、命令キャッシュをどうやって破棄するかがやはり問題になって詰んだ。
Re: (スコア:0)
>任意のコードの実行が可能になる
ここが無理。隣接ラインのどのビットが化けるか、値がどう化けるかは攻撃者からは制御できない。
Re: (スコア:0)
何故かマイナスされてるけどこの手のヨタと同種という認識で正しいだろ
非常に限定された状況や、別の巨大なセキュリティホールがある前提でないと成立しない様な
取るに足らない脆弱性をいちいち騒ぐ事はセキュリティの向上には資さない
三流セキュリティ屋に餌をやるだけ。セキュリティをネタに学生が卒論書くときに使えますね、ってレベル。
笑い飛ばしてネタにする以外にどうしろというのか。
そんなもんを心配する暇があるなら暴走自動車が突然突っ込んできて死ぬ可能性を心配をした方がよほどマシ
Re: (スコア:0)
これは非常に限定された状況ですか?
どこか特定の場所にある命令を繰り返しただけで隣接した別の場所の内容が破壊されるというのは問題視されても仕方ないでしょう。
対策としてはECCの強化とかになるんでしょうか。
Re: (スコア:0)
非常に限定されたかどうかは、具体的な攻撃内容が書いてないので判断できない。
その内容をどう想像したかによって、ネタ的な話と捉えるのか、問題あると捉えるのかに分かれたのでしょう。
上記には、まるでソフトのみで起こせるような書き方ですが、詳細は書いてません、予定外の電圧変動を与えながらやるのが前提かもしれません。
誰か詳細な内容わかる人いませんか?
Re: (スコア:0)
その例で言うなら、貴方の隣を走っている自動車を、第三者がいつでも簡単に暴走させられます、という脆弱性なんだが。
危険だと思わない?
Re: (スコア:0)
横レス失礼。
隣で走ってる自動車の前にでて立ちはだかって車を止めさせ、
運転手を引きずり出して運転席に乗り込んだら、
簡単に暴走させられます、みたいな?
例え話はよせって、ここで何度も言われてることだと思うんだけど。
Re: (スコア:0)
>例え話はよせって、ここで何度も言われてることだと思うんだけど。
それは元元コメに言うべき。
Re: (スコア:0)
>暴走自動車が突然突っ込んできて死ぬ可能性を心配をした方がよほどマシ
と言う部分が例えだと思って読んでるなら、この脆弱性を心配する前に自分の頭を心配しろ
Re: (スコア:0)
クラウドでいろんな人と一緒に同じノードに詰め込まれると、隣が悪いやつだった場合に影響が漏れてくるよっていう
サイドチャネルの話はいくつかあるけど主にその関係じゃないか