本来アクセスできないメモリ領域のデータを読み出せる可能性がある脆弱性が見つかる、多くのCPUに影響 32
なるほど 部門より
どうも報道規制があるようでよく分からないのだが、少なくとも現行のIntel製CPUに脆弱性があり、カーネルメモリをユーザプロセスやWebページに組み込まれたJavaScriptなど様々なユーザ空間プロセスから読み出せる可能性があるようだ(4chan.org、TechCrunch)。対策として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においてはすでに対応パッチが提供されているという。
Azureがあわててアップデート実施 (スコア:2, 参考になる)
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に詳細が公開されるって書いてあるんだし、前倒しで公開することにセキュリティ上のメリットなんてないだろ。
相変わらず勝手な会社だな。
Re: (スコア:0)
自分のところは事前に対応してからばらすとかえげつないですな。
Re: (スコア:0)
詳細が書いてない→どっからリークしたのか分からない→一流クラッカーは既に情報を仕入れている可能性がある、ってことでは?
そうでなくても、ヒントがあれば具体的なやり方を開発できる人も多いだろうし。
もしかしたらできる可能性があるかも知れない、というやり口に多大な手間を突っ込むのは躊躇われるけど、
やればできるらしい、だったら話は大きく変わってくる。
Re: (スコア:0)
The Registerが記事にしたのは話題になってからだよ。この辺り [tumblr.com]から少しずつPoCが漏れたり [twitter.com]してたから前倒しせざるを得なかったんだよ。
詳細不明だとパッチも当てられないし影響評価もできないから、漏れた以上は公開するのは正しい。そこについては各社とも異論はないはずだよ。あるなら挙げてみ?
スマホもか (スコア:2)
iOS端末やAndroid端末もかなり影響を受けるでしょうね
でも日本キャリアのAndroid端末は
基本的に発売後1年ぐらいでアップデートが
期待できなくなってしまっているのが残念です
本格対応は来週みたいからですので年始はこれの対応ですかね・・・
個人的にはお客様のシステムのアプライアンスの中身が
Xeon積んでるものがあるのでどの程度の影響があるか見えないですね
# もっと影響があるのはIoT系かなあ
Re:スマホもか (スコア:1)
いつからだったかdocomo発売の機種は発売後2年までアップデート対象になったようです。
# 2015年か2014年の春夏モデル辺りからだった気がする。
macOSのステータス (スコア:1)
SpectreやMeltdownの詳細は、読んでもさっぱりわからんのですが、Macでは10.13.3でKernel page table isolationの問題について修正が入ってるようです。
遅くなっているのに告知しない体質はAppleらしいですが、暫定措置的な対応は行われたようです。
Haswell以降はそんな影響ないよな話しも出ていますが、家のSandyちゃんなMac miniを今アップグレードしていますが、どんなものでしょう。
自分の理解ではシステムコール、プロセス間通信、カーネルとのメモリ転送がやばいのかなと思いますが、
鯖屋さんは阿鼻叫喚なのでしょうか?DB屋さんもか
Re:macOSのステータス (スコア:1)
10.13.2ですた。ごめんね。
Re: (スコア:0)
>遅くなっているのに告知しない体質はAppleらしいですが
この件に関してはほかのOSもひっそりやってんだからAppleだけそう非難するのは違うような気もしますが。
Re: (スコア:0)
Googleの記事ではHaswell Xeonで検証されてるけど該当の機能はSandy Bridgeから搭載みたいね。
7年前のCPUだけど対応してくれるかしら。
Re: (スコア:0)
該当の機能はPentium IIIくらいから搭載されてるよ。
おいおい (スコア:1)
とりあえずx86-pti-for-linus git tree [kernel.org]見てこい
報道規制どころか31日にはもうLKML大騒ぎでtree切るほどだったわ
どんだけ情報遅れてんだ
おまえら日本語で出てくるまでなにもしねーのか(呆れ
Re:おいおい (スコア:1)
じゃあたれ込んでよ。
Re: (スコア:0)
いちいちお前に教えてやらなきゃ報道規制なのか…
Re: (スコア:0)
なんで?
技術的な話ならMLでの議論に参加すればいいじゃない。
野次馬として楽しみたいなら、たくさん乱立してるredditとかでもいい。
Re: (スコア:0)
迅速な対応っぷりを見るに、関係者には事前に根回しされてたっぽいですね
Re: (スコア:0)
> どんだけ情報遅れてんだ
いいがかりはやめてください。
ここは旬を過ぎた情報を短時間だけ話し合う場所です。
訂正が必須 (スコア:1)
> 対策としてLinuxカーネルやWindows NT系OSにおいてカーネルメモリ空間へASLRの導入がひっそりと進んでおり
ASLRを突破できるからこの脆弱性は危険なのですよ。
AMD製CPUでは影響が少ないということは (スコア:1)
x86の命令セットに由来するものではないってことだよね?
インテルのマイクロアーキテクチャに問題があるのか、インテルだけにある命令セット(VT系)に問題があるんだろうか。
ただ完全にマイクロアーキテクチャ依存ではなさそうなのは、影響の度合いはともかく、AMDにもARMにも問題があるらしいということ。
Ryzen以前にならHyperthreadingに問題が!、だったんだけど、それもARMが影響がないってことは関係なさそう。
ASLRの導入で緩和できるなら、32bit OSはメモリ空間が小さくてやばそう。
Re: (スコア:0)
少なくとも3日に情報が出た時点では、FPGAでは修正できない重大な問題としてました
つまり、アーキテクチャに関するアルゴリズムが今回影響しているものと思われます。
なのでその機能を無効にして代替する機能をソフトウェアで実現させようとするから
CPuのパフォーマンスが落ちるといことではないかと、、、、
やっぱりPentiumIIIに内蔵されてた個を特定するシリアルナンバー機能が必要なんでないかい??
Re: (スコア:0)
捨てられた投機実行の結果は完全には消えてなくて測定可能で、
投機実行の実装方法がIntelのHaswellのマニュアルには比較的詳しく出ていたのでそれを手がかりに
狙った先を投機実行させるようにする方法をひねり出したてことのようです。
この実現された手法がHawell用ってだけで、同様なことのAMDでの実現方法を見つけることはあり得ないってことは無いように思います。
Re: (スコア:0)
ここ [gigazine.net]によるとメルトダウンは
> 投機的実行における推測的なメモリの参照が許可されていないためメルトダウンの影響を受けない
> AMD製CPUにLinuxパッチを適用するとパフォーマンスが落ちるので、有効にしないように、
> との注意喚起をAMD技術者のTom Lendacky氏は行っています。
と書いてある。
JavaScriptから (スコア:0)
可能なの?WebAssemblyとか使うのかな?
Re: (スコア:0)
ARMのホワイトペーパーに載ってるやつなら、
キャッシュのヒット・ミスヒットを判別できるくらいの
高精度タイマーにアクセスできれば使えますね。
何度もやれば普通のタイマーでもいけるのかなあ。
CPUを100%使う事が無いので (スコア:0)
35%低下しても気づかないかもしれん・・・
prefetch止めてみるか (スコア:0)
BIOSに設定項目に
CPUのハードウェア プリフェッチがあれば
無効にしておくことで気休めにはなるかな
ノートには項目なかったが
自作のデスクトップにはあったんで
念のためパフォーマンス犠牲で対処してみますかね
IntelからIntel-SA-000xx Detection Toolがでて確認できるまで
/*
AMDに移行したとしても
ハードウェア プリフェッチの扱いしだいで
回避できない気がしなくもない
*/
重要度がどの程度なのやら (スコア:0)
「PCが30%遅くなる!」という分かりやすい煽り文句が先行してWebメディアが騒ぎ立てていることもあって
実際のところどの程度ヤバい問題なのかが分からん。
30%とか35%とかいう数字がある一方で、実際は数%という話もあるし、
AMD製CPUに影響があるのか無いのかどうにもハッキリしないし、
誰でも簡単にパスワードを盗み見できるという話もあれば、実際に攻撃に転用するのはかなり難しいという話もある。
OSのパッチで対処できるのか、できないのかも分からん。
できれば情報が出揃うまで静観したいと思うけど、
たぶん明日あたりまとめ系サイトでも見た上司が、早くなんとかしろ!と騒ぎ出しそうな予感・・・・
Re: (スコア:0)
サーバが30%遅くなる対処方しかないとしてもその対処方を取る他ないといえばどれくらいやばいかわかるだろ?
少なくともハートブリードよりはまずい。
Re: (スコア:0)
あそこまで簡単に情報を取れるの?
SSL heartbleedはPoC時点でヤバいのがわかったけど
今回のが本当にそこまで簡単に悪用できるのかは(まだ)疑問なのでは?
Atomの時代が来るのか(来ない) (スコア:0)
っても、今のじゃなくてインオーダーのもっさりAtomだけど。
投機実行がなければ影響ないんだよね?
Re: (スコア:0)
よくわからんが
Pentium(atom)とかセレロン(atom)みたいなのあるけどあいつらはセーフなのか?
概要 (スコア:0)
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も含め全滅