パスワードを忘れた? アカウント作成
13495398 story
Intel

本来アクセスできないメモリ領域のデータを読み出せる可能性がある脆弱性が見つかる、多くのCPUに影響 32

ストーリー by hylom
なるほど 部門より
あるAnonymous Coward 曰く、

どうも報道規制があるようでよく分からないのだが、少なくとも現行のIntel製CPUに脆弱性があり、カーネルメモリをユーザプロセスやWebページに組み込まれたJavaScriptなど様々なユーザ空間プロセスから読み出せる可能性があるようだ(4chan.orgTechCrunch)。対策としてLinuxカーネルやWindows NT系OSにおいてカーネルメモリ空間へASLRの導入がひっそりと進んでおり、Amazon、Google、Microsoftなどクラウドサービス事業各社は大規模なアップグレードを早いところでは来週にも計画している。

影響される利用形態はVPSにとどまらずデスクトップも含まれるが、対象のハードウェアがIntel Coreシリーズプロセッサやその一部で収まるのか、Core 2 Duoやそれ以前、またVIA Technologiesなど他社へ拡張されるかは不明だ。AMDは自社製品についてそのようなバグの影響を受けないと回答している。Linux Kernelにおいてはこの機能を有効にするフラグは X86_BUG_CPU_INSECURE と名付けられ、AMD製ではないすべてのx86プロセッサで有効になるよう設定されている。有効にすることによる性能低下は最大で35%弱となるようだ。

この脆弱性はGoogleのセキュリティチームProject Zeroによって発見されたもので、3日付けで解説記事が公開されている。昨今の多くのCPUに搭載されている投機的実行機能を悪用するもので、2017年6月にIntelおよびAMD、ARMにこの脆弱性を報告していたとのこと。この脆弱性を突く実証コード(PoC)も開発されている。

Project Zeroの発表では、3種類の脆弱性が提示されている。これに対しAMDは声明を発表、AMDのCPUにおいてこれらのうち1つは影響があるもののソフトウェアやOSの修正で対応できるとし、その場合の性能への影響もほとんどないとしている。また、1つは未検証ながらリスクは0に近く、1つは影響しないとしている。

また、ARMもこれについての情報を公開している。これによると、一部のCortexシリーズプロセッサがこの脆弱性の影響を受けるとのことだが、Linuxにおいてはすでに対応パッチが提供されているという。

関連リンク

  • by Anonymous Coward on 2018年01月04日 20時39分 (#3339845)

    The Registerがスクープし、Googleが勝手に詳細をばらしたもんだから、Azureがばたばたしとる。

    マイクロソフト、CPUの脆弱性対策でAzureの計画メンテを前倒し、全リージョンの仮想マシンを今朝から強制再起動。Googleは対策済みと発表 [publickey1.jp]

    「当初の予定では1月9日まであいだユーザー自身が時期を選んで再起動」とあるから、
    おそらくこの脆弱性の公開期日(1/9)に合わせたメンテナンススケジュールだったと思われる。
    これが前倒しされて、ユーザーにとっては事前の時間予告なしでインスタンスが強制再起動されることになってしまった。

    AWSでも1/4~1/5のメンテナンス期間を予定しており、脆弱性公開時点で若干のインスタンスが未更新のようだ。

    てか、ニュースが流れたといってもThe Registerには詳細は書いてなかったんだから、
    Googleが詳細をバラさなけりゃこんなことせずに済んだんじゃないのかね。
    The Registerにも1/9に詳細が公開されるって書いてあるんだし、前倒しで公開することにセキュリティ上のメリットなんてないだろ。
    相変わらず勝手な会社だな。

    ここに返信
    • by Anonymous Coward

      自分のところは事前に対応してからばらすとかえげつないですな。

    • by Anonymous Coward

      詳細が書いてない→どっからリークしたのか分からない→一流クラッカーは既に情報を仕入れている可能性がある、ってことでは?

      そうでなくても、ヒントがあれば具体的なやり方を開発できる人も多いだろうし。
      もしかしたらできる可能性があるかも知れない、というやり口に多大な手間を突っ込むのは躊躇われるけど、
      やればできるらしい、だったら話は大きく変わってくる。

    • by Anonymous Coward

      The Registerが記事にしたのは話題になってからだよ。この辺り [tumblr.com]から少しずつPoCが漏れたり [twitter.com]してたから前倒しせざるを得なかったんだよ。
      詳細不明だとパッチも当てられないし影響評価もできないから、漏れた以上は公開するのは正しい。そこについては各社とも異論はないはずだよ。あるなら挙げてみ?

  • by kawakazu (45966) on 2018年01月04日 21時34分 (#3339868) 日記
    SpectreはARMも対象になってるので
    iOS端末やAndroid端末もかなり影響を受けるでしょうね

    でも日本キャリアのAndroid端末は
    基本的に発売後1年ぐらいでアップデートが
    期待できなくなってしまっているのが残念です

    本格対応は来週みたいからですので年始はこれの対応ですかね・・・

    個人的にはお客様のシステムのアプライアンスの中身が
    Xeon積んでるものがあるのでどの程度の影響があるか見えないですね

    # もっと影響があるのはIoT系かなあ
    ここに返信
  • by shesee (27226) on 2018年01月04日 20時14分 (#3339822) 日記

    SpectreやMeltdownの詳細は、読んでもさっぱりわからんのですが、Macでは10.13.3でKernel page table isolationの問題について修正が入ってるようです。
    遅くなっているのに告知しない体質はAppleらしいですが、暫定措置的な対応は行われたようです。
    Haswell以降はそんな影響ないよな話しも出ていますが、家のSandyちゃんなMac miniを今アップグレードしていますが、どんなものでしょう。

    自分の理解ではシステムコール、プロセス間通信、カーネルとのメモリ転送がやばいのかなと思いますが、
    鯖屋さんは阿鼻叫喚なのでしょうか?DB屋さんもか

    ここに返信
    • by shesee (27226) on 2018年01月04日 20時17分 (#3339826) 日記

      10.13.2ですた。ごめんね。

    • by Anonymous Coward

      >遅くなっているのに告知しない体質はAppleらしいですが
      この件に関してはほかのOSもひっそりやってんだからAppleだけそう非難するのは違うような気もしますが。

    • by Anonymous Coward

      Googleの記事ではHaswell Xeonで検証されてるけど該当の機能はSandy Bridgeから搭載みたいね。
      7年前のCPUだけど対応してくれるかしら。

      • by Anonymous Coward

        該当の機能はPentium IIIくらいから搭載されてるよ。

  • by Anonymous Coward on 2018年01月04日 20時25分 (#3339830)

    とりあえずx86-pti-for-linus git tree [kernel.org]見てこい
    報道規制どころか31日にはもうLKML大騒ぎでtree切るほどだったわ
    どんだけ情報遅れてんだ
    おまえら日本語で出てくるまでなにもしねーのか(呆れ

    ここに返信
    • by Anonymous Coward on 2018年01月04日 20時41分 (#3339847)

      じゃあたれ込んでよ。

      • by Anonymous Coward

        いちいちお前に教えてやらなきゃ報道規制なのか…

      • by Anonymous Coward

        なんで?
        技術的な話ならMLでの議論に参加すればいいじゃない。
        野次馬として楽しみたいなら、たくさん乱立してるredditとかでもいい。

    • by Anonymous Coward

      迅速な対応っぷりを見るに、関係者には事前に根回しされてたっぽいですね

    • by Anonymous Coward

      > どんだけ情報遅れてんだ
       
      いいがかりはやめてください。
      ここは旬を過ぎた情報を短時間だけ話し合う場所です。

  • by Anonymous Coward on 2018年01月04日 20時30分 (#3339835)

    > 対策としてLinuxカーネルやWindows NT系OSにおいてカーネルメモリ空間へASLRの導入がひっそりと進んでおり

    ASLRを突破できるからこの脆弱性は危険なのですよ。

    ここに返信
  • by Anonymous Coward on 2018年01月04日 20時31分 (#3339837)

    x86の命令セットに由来するものではないってことだよね?
    インテルのマイクロアーキテクチャに問題があるのか、インテルだけにある命令セット(VT系)に問題があるんだろうか。

    ただ完全にマイクロアーキテクチャ依存ではなさそうなのは、影響の度合いはともかく、AMDにもARMにも問題があるらしいということ。

    Ryzen以前にならHyperthreadingに問題が!、だったんだけど、それもARMが影響がないってことは関係なさそう。
    ASLRの導入で緩和できるなら、32bit OSはメモリ空間が小さくてやばそう。

    ここに返信
    • by Anonymous Coward

      少なくとも3日に情報が出た時点では、FPGAでは修正できない重大な問題としてました
      つまり、アーキテクチャに関するアルゴリズムが今回影響しているものと思われます。

      なのでその機能を無効にして代替する機能をソフトウェアで実現させようとするから
      CPuのパフォーマンスが落ちるといことではないかと、、、、

      やっぱりPentiumIIIに内蔵されてた個を特定するシリアルナンバー機能が必要なんでないかい??

    • by Anonymous Coward

      捨てられた投機実行の結果は完全には消えてなくて測定可能で、
      投機実行の実装方法がIntelのHaswellのマニュアルには比較的詳しく出ていたのでそれを手がかりに
      狙った先を投機実行させるようにする方法をひねり出したてことのようです。
      この実現された手法がHawell用ってだけで、同様なことのAMDでの実現方法を見つけることはあり得ないってことは無いように思います。

      • by Anonymous Coward

        ここ [gigazine.net]によるとメルトダウンは

        > 投機的実行における推測的なメモリの参照が許可されていないためメルトダウンの影響を受けない
        > AMD製CPUにLinuxパッチを適用するとパフォーマンスが落ちるので、有効にしないように、
        > との注意喚起をAMD技術者のTom Lendacky氏は行っています。

        と書いてある。

  • by Anonymous Coward on 2018年01月04日 20時17分 (#3339825)

    可能なの?WebAssemblyとか使うのかな?

    ここに返信
    • by Anonymous Coward

      ARMのホワイトペーパーに載ってるやつなら、
      キャッシュのヒット・ミスヒットを判別できるくらいの
      高精度タイマーにアクセスできれば使えますね。
      何度もやれば普通のタイマーでもいけるのかなあ。

  • by Anonymous Coward on 2018年01月04日 20時32分 (#3339838)

    35%低下しても気づかないかもしれん・・・

    ここに返信
  • by Anonymous Coward on 2018年01月04日 20時41分 (#3339848)

    BIOSに設定項目に
    CPUのハードウェア プリフェッチがあれば
    無効にしておくことで気休めにはなるかな

    ノートには項目なかったが
    自作のデスクトップにはあったんで
    念のためパフォーマンス犠牲で対処してみますかね
    IntelからIntel-SA-000xx Detection Toolがでて確認できるまで

    /*
    AMDに移行したとしても
    ハードウェア プリフェッチの扱いしだいで
    回避できない気がしなくもない
    */

    ここに返信
  • by Anonymous Coward on 2018年01月04日 21時03分 (#3339862)

    「PCが30%遅くなる!」という分かりやすい煽り文句が先行してWebメディアが騒ぎ立てていることもあって
    実際のところどの程度ヤバい問題なのかが分からん。

    30%とか35%とかいう数字がある一方で、実際は数%という話もあるし、
    AMD製CPUに影響があるのか無いのかどうにもハッキリしないし、
    誰でも簡単にパスワードを盗み見できるという話もあれば、実際に攻撃に転用するのはかなり難しいという話もある。
    OSのパッチで対処できるのか、できないのかも分からん。

    できれば情報が出揃うまで静観したいと思うけど、
    たぶん明日あたりまとめ系サイトでも見た上司が、早くなんとかしろ!と騒ぎ出しそうな予感・・・・

    ここに返信
    • by Anonymous Coward

      サーバが30%遅くなる対処方しかないとしてもその対処方を取る他ないといえばどれくらいやばいかわかるだろ?
      少なくともハートブリードよりはまずい。

      • by Anonymous Coward

        あそこまで簡単に情報を取れるの?
        SSL heartbleedはPoC時点でヤバいのがわかったけど
        今回のが本当にそこまで簡単に悪用できるのかは(まだ)疑問なのでは?

  • by Anonymous Coward on 2018年01月04日 21時52分 (#3339876)

    っても、今のじゃなくてインオーダーのもっさりAtomだけど。
    投機実行がなければ影響ないんだよね?

    ここに返信
    • by Anonymous Coward

      よくわからんが
      Pentium(atom)とかセレロン(atom)みたいなのあるけどあいつらはセーフなのか?

  • by Anonymous Coward on 2018年01月04日 22時11分 (#3339891)

    googleのレポート [blogspot.jp]

    問題は以下の3種
    ・Variant 1: bounds check bypass (CVE-2017-5753)
    ・Variant 2: branch target injection (CVE-2017-5715)
    ・Variant 3: rogue data cache load (CVE-2017-5754)

    脆弱性は以下の2つに分類して命名されている
     Spectre (variants 1 and 2)
     Meltdown (variant 3)

    ■Spectre はLinuxでの話
    eBPFという仕組みを経由してカーネルの情報を取得する手法
    Linux環境内に入ってからの話だし一般ユーザには関係ない?
    AMDはvariants 1に対してはOSアプデにより解決、またそれによるパフォーマンスの影響も微々
    variants 2に対しては設計の違いによりほぼゼロリスク、また再現もされてない

    仮想サーバ関係者は大変
    ちなみにAMDはデフォルトでは無効の ePBF JIT が有効になっている場合にのみ影響があるとのこと
    それも ePBF JIT の脆弱性に起因しているのでこれが修正されれば問題ない

    ■Meltdown はIntel CPUの脆弱性の話
    カーネルモードで使った領域がL1Dキャッシュに残っていてユーザ権限から読めちゃうと書かれている
    性能面でやばいのもこっち
    AMDは設計の違いによりゼロリスク
    IntelはNorthwood以降Xeonも含め全滅

    ここに返信
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...