本来アクセスできないメモリ領域のデータを読み出せる可能性がある脆弱性が見つかる、多くのCPUに影響 258
なるほど 部門より
どうも報道規制があるようでよく分からないのだが、少なくとも現行の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があわててアップデート実施 (スコア:5, 参考になる)
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:Azureがあわててアップデート実施 (スコア:1)
昨年12月頃にAzureから計画メンテナンスの通知が確かに来てたけどこれだったのか…
# mishimaは本田透先生を熱烈に応援しています
Re:Azureがあわててアップデート実施 (スコア:1)
「今回のケースではGoogleは数か月前にIntelにコンタクトを取っている。もちろん程度の差はあれ、問題の存在を知っていたメーカーは多いはずだ。Microsoftが理由を明かさずにパッチをリリースしていたのもその一例だろう。Linuxの各種ディストリビューションも、脆弱性については詳細を示さないまま、アップデートを行っていた。」
「しかしThe Registerがいくつかの情報をつなぎ合わせスクープ記事を出した。そのためIntelは来週に予定していた共同発表の前に急きょ「報道は不正確だ」という反論の声明を発表するなどの対応に追われることになったわけだ。」
http://jp.techcrunch.com/2018/01/05/2018-01-03-kernel-panic-what-are-m... [techcrunch.com]
こっちだとこんな風に書かれてますね。
Re:Azureがあわててアップデート実施 (スコア:3, おもしろおかしい)
CPU自前で設計してて、Aのつく某社って、AMDかARMかAppleかAtmelか…多すぎてわからん
Re:Azureがあわててアップデート実施 (スコア:2)
昔はもっと酷いCPUバグや性能低下パッチもあったんだぞ。
これが噂の Intel 信者か。 (スコア:1, おもしろおかしい)
本当に警察沙汰になるといいね。
概要 (スコア:5, 参考になる)
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も含め全滅
Re:概要 (スコア:4, 参考になる)
Meltdownはそんな単純な話ではないのでは。
カーネル空間のあるアドレスの内容を投機的にアドレスとして用いてメモリラインをキャッシュさせ、
どのキャッシュラインが埋められてるかタイミングを測ることでカーネルメモリの値を推定すると読めました:
https://meltdownattack.com/meltdown.pdf [meltdownattack.com]
Re:概要 (スコア:1)
メモリーから読み出した内容をインデックスとして別のメモリー領域を読み出して(ここら辺の処理を全て投機実行)、
どこのメモリー領域を読み出したかをアクセス速度(一度読みだしている場合はキャッシュにヒットして速い)で判別して元のメモリー内容を推測するってのがキモのようです。
全て破棄するのは手間も時間も掛かりそうですね。
KPTIパッチを当てたlinuxのベンチマーク結果 (スコア:5, 興味深い)
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86p... [phoronix.com]
https://www.phoronix.com/scan.php?page=article&item=linux-more-x86... [phoronix.com]
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initia... [phoronix.com]
https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm... [phoronix.com]
Re:KPTIパッチを当てたlinuxのベンチマーク結果 (スコア:1)
> Linux Kernelにおいてはこの機能を有効にするフラグは X86_BUG_CPU_INSECURE と名付
> けられ、AMD製ではないすべてのx86プロセッサで有効になるよう設定されている。
これについても、phoronix に記事がありました。
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-... [phoronix.com]
Linuxカーネルのアップデート後もAMD製CPUユーザは特にカーネルオプションなど設定しな
くても、KPTIパッチは無効になるようです。
それから、AMD製以外のCPUで無効にするにはカーネルオプション nopti 付きで起動すれば
良いと。
おいおい (スコア:2, 参考になる)
とりあえずx86-pti-for-linus git tree [kernel.org]見てこい
報道規制どころか31日にはもうLKML大騒ぎでtree切るほどだったわ
どんだけ情報遅れてんだ
おまえら日本語で出てくるまでなにもしねーのか(呆れ
Re:おいおい (スコア:2, すばらしい洞察)
じゃあたれ込んでよ。
Re:おいおい (スコア:1)
そんな所で議論するのも、垂れ込まないのも勝手ですけど、
わざわざここに乗り込んで上から目線のコメントとかいらないです。
Re:おいおい (スコア:2)
訂正が必須 (スコア:2, すばらしい洞察)
> 対策としてLinuxカーネルやWindows NT系OSにおいてカーネルメモリ空間へASLRの導入がひっそりと進んでおり
ASLRを突破できるからこの脆弱性は危険なのですよ。
Re:訂正が必須 (スコア:2, 参考になる)
ちょこっとウィキのCiteにあった論文読んでみたらKASLRなんて屁でもないと簡単にカーネルメモリ読み出せるらしい。
KAISER(KPTI)じゃないとmeltdownは防げないと。
んでSkylake以降だとあんま性能落ちませんよだと。
Windowsだとプロセス毎にカーネルメモリ丸見え(スワップアウトされてない部分)だから、どうしようもないって話だと。
スマホもか (スコア:2)
iOS端末やAndroid端末もかなり影響を受けるでしょうね
でも日本キャリアのAndroid端末は
基本的に発売後1年ぐらいでアップデートが
期待できなくなってしまっているのが残念です
本格対応は来週みたいからですので年始はこれの対応ですかね・・・
個人的にはお客様のシステムのアプライアンスの中身が
Xeon積んでるものがあるのでどの程度の影響があるか見えないですね
# もっと影響があるのはIoT系かなあ
Re:スマホもか (スコア:1)
いつからだったかdocomo発売の機種は発売後2年までアップデート対象になったようです。
# 2015年か2014年の春夏モデル辺りからだった気がする。
Re:スマホもか (スコア:1)
JavascriptでもExploit成立するんだなこれが
Re:スマホもか (スコア:1)
> JavascriptでもExploit成立するんだなこれが
成立したと言ってるが、実際の前提がまったく不明の典型的なFUDだけどな、それ
さらに言えばそんなことに使えるほどの高精度タイマは今回の件以外でもセキュリティ問題につながるので
各ブラウザともに排除に向かっている
Re:スマホもか (スコア:1)
Jabascript
愛(i)が足りない (スコア:2)
JavascriptとVBSのBasicを合成した高度な言葉遊びとか
macOSのステータス (スコア:1)
SpectreやMeltdownの詳細は、読んでもさっぱりわからんのですが、Macでは10.13.3でKernel page table isolationの問題について修正が入ってるようです。
遅くなっているのに告知しない体質はAppleらしいですが、暫定措置的な対応は行われたようです。
Haswell以降はそんな影響ないよな話しも出ていますが、家のSandyちゃんなMac miniを今アップグレードしていますが、どんなものでしょう。
自分の理解ではシステムコール、プロセス間通信、カーネルとのメモリ転送がやばいのかなと思いますが、
鯖屋さんは阿鼻叫喚なのでしょうか?DB屋さんもか
Re:macOSのステータス (スコア:2)
まだあったのかPC WORLD [pcworld.com]
Linus Torvalds 「“Some loads will hardly be affected at all, if they just spend all their time in user space. And if you do a lot of small system calls, you might see double-digit slowdown.
“It will depend heavily on the hardware too,” he continued. “Older CPUs without PCID will be impacted more by the isolation. And I think some of the back-ports won’t take advantage of PCID even on newer hardware.” 」
なのでSandyちゃん駄目かも。
Re:macOSのステータス (スコア:1)
10.13.2ですた。ごめんね。
Re: (スコア:0)
>遅くなっているのに告知しない体質はAppleらしいですが
この件に関してはほかのOSもひっそりやってんだからAppleだけそう非難するのは違うような気もしますが。
Re:macOSのステータス (スコア:1)
Sandyちゃんのcpu.features見たら確かにPCIDあった。
さよなら、Core2duo もうAppleに引き取られたけど。
Windows10の暫定パッチはSkylakeが境界との話しもあるので心配。Skylake? SGX? まさかねぇ
Re:macOSのステータス (スコア:1)
Older CPUs without PCID will be impacted more by the isolation.
KPTI(Kernel page table isolation)というのはMeltdown軽減策の名前。そのものではない。
PCID機能があればKPTI実装上の重い処理を省けて性能低下が抑えられるだけで、Meltdown自体はPCIDと関係なくCore 2 Duoにもある。
Re:macOSのステータス (スコア:1)
ありがと。
そこら辺わかってるよ。
投機実行を利用してキャッシュにロードしたカーネルメモリをサイドチャンネル攻撃でキャッシュのどの位置にあるのか特定した後、どうやって読み込むか分からない。
キャッシュラインは結びついたメモリアドレスの特権モードを引き継ぐはずなんだけど。
よくあることです (スコア:1)
>時間に変換して測定
暗号関連で内部状態を推測する方法として、処理時間を図る/観察する。という手法(サイドチャネル攻撃)は定番で、
最新の暗号/ハッシュアルゴリズムは、処理時間から内部状態を推測されないように設計されるようになっています。
けど、実装によっては問題出ちゃうんだけどね。
なので、その手の分野では、かなり普通の方法ですな
Re:macOSのステータス (スコア:1)
俺の3770はまだ使えるな、問題ない。
AMD製CPUでは影響が少ないということは (スコア:1)
x86の命令セットに由来するものではないってことだよね?
インテルのマイクロアーキテクチャに問題があるのか、インテルだけにある命令セット(VT系)に問題があるんだろうか。
ただ完全にマイクロアーキテクチャ依存ではなさそうなのは、影響の度合いはともかく、AMDにもARMにも問題があるらしいということ。
Ryzen以前にならHyperthreadingに問題が!、だったんだけど、それもARMが影響がないってことは関係なさそう。
ASLRの導入で緩和できるなら、32bit OSはメモリ空間が小さくてやばそう。
Re:AMD製CPUでは影響が少ないということは (スコア:1)
捨てられた投機実行の結果は完全には消えてなくて測定可能で、
投機実行の実装方法がIntelのHaswellのマニュアルには比較的詳しく出ていたのでそれを手がかりに
狙った先を投機実行させるようにする方法をひねり出したてことのようです。
この実現された手法がHawell用ってだけで、同様なことのAMDでの実現方法を見つけることはあり得ないってことは無いように思います。
Re:AMD製CPUでは影響が少ないということは (スコア:1)
ここ [gigazine.net]によるとメルトダウンは
> 投機的実行における推測的なメモリの参照が許可されていないためメルトダウンの影響を受けない
> AMD製CPUにLinuxパッチを適用するとパフォーマンスが落ちるので、有効にしないように、
> との注意喚起をAMD技術者のTom Lendacky氏は行っています。
と書いてある。
Re:AMD製CPUでは影響が少ないということは (スコア:1)
デモ動画 [youtube.com]が公開されていて、簡単にパスワードを盗んでいる。
アドレスさえわかれば読めるみたいだな。
読める範囲を全部読めめば、パスワードを手に入れられそう。
KB4056892の不具合 (スコア:1)
マイクロソフトからKB4056892がリリースされましたが、AMD Athlon 64 X2環境ではアップデート中の再起動直後にハングアップしてしまいます。
ハングアップ後のハードウェアリセットを2回行えば、自動でロールバックされ正常に起動しますが、修正プログラムは適応されません。
http://www.windows-10-forum.com/threads/windows-startet-nicht-mehr-wae... [windows-10-forum.com]
https://social.technet.microsoft.com/Forums/es-ES/209626d5-3fe0-4143-9... [microsoft.com]
JavaScriptから (スコア:0)
可能なの?WebAssemblyとか使うのかな?
Re:JavaScriptから (スコア:5, 参考になる)
Firefoxは高精度タイマー使えなくするってよ
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-c... [mozilla.org]
Re:JavaScriptから (スコア:4, 参考になる)
Chromeも1/23リリースの次のバージョンから高精度タイマーの精度下げるようですね
https://www.chromium.org/Home/chromium-security/ssca [chromium.org]
EdgeとIEも同様の対応をすませたもよう。
https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-m... [windows.com]
また、三ブラウザ共に SharedArrayBuffer (EdgeではFall Creators Updateで実装した新機能)を無効化する、ようです。
SharedArrayBuffer はmozillaのブログによれば闇に葬るのではなく、また有効化可能にできるよう頑張るみたい
Re:重要度がどの程度なのやら (スコア:2)
Re:重要度がどの程度なのやら (スコア:2)
PCI Expのスループットが落ちなきゃほとんど影響がないのでは。
まあ,会社の場合,買い換え稟議を通すチャンスよね,本来。
Re:重要度がどの程度なのやら (スコア:1)
30%以上のインパクトがあるのは、IOを大量に発行するデータベース、 Webサーバーだと思う。
クライアントは言うても大したことない。
Webサーバーは増やせばいいけど、
データーベースの性能が30%落ちるとなると、サーバー構成を根本的に見直さざるを得ないかもしれん。
Windowsも緊急リリースでパッチが出とる。
Intelどうするんやろ。賠償に備えて手元資金を厚くするとなると、10nmプロセスは永遠に立ち上がらんかもしれん。
そのかわり、すべてのメモリを取得可能なんだ (スコア:1)
ハートブリードはバッファの近くの特定メモリ領域しか取得できないから、おいしいデータがとれるかどうかは運しだい。
ただしリモートから攻撃できるから大事に。
今回は、同一マシン上で動いていなければいけないけれど、
2Kbyte/sec の速度で、主記憶の全メモリを見ることが可能。
Re:ぶかっけ何が強烈かと言ってしまうと (スコア:3, おもしろおかしい)
ちょっとあなた、普段の性癖がダダ漏れですよ!
うどん県民の叫び (スコア:1)
やかましいぶっかけうどんとかあるんだよ性癖無関係なんだよ!
Re:ぶかっけ何が強烈かと言ってしまうと (スコア:2)
パスワードよりも、何らかの秘密鍵を狙う方が容易っぽいかもしらない。
だから、クラウド方面が必死になっているふいんきなわけで。
Re:ぶかっけ何が強烈かと言ってしまうと (スコア:2)
実装次第なところがあるけど、HW仮想化環境でも、この脆弱性は影響が有るのかな?
無さそうな気がするする。
例えば、隠したい領域をMMUから見えなくすれば防げるだろうし。
Re:ぶかっけ何が強烈かと言ってしまうと (スコア:2)
なぜのかXenのpara virtualization modeを挙げているのに、full virtualization modeを挙げない。
Re:知りたいのは (スコア:4, 興味深い)
> 対象になるCPUのモデルは何か
Meltdown: Intel Pentium III か Pentium 4 ~ 第8世代 Intel Core (Coffee Lake)、および現時点で設計が完了しているx86/x64プロセッサ、
ただし一部の構造が単純な初期のIntel AtomやIntel Quark製品などは除く。PC-98華やかなりし頃まで遡れば影響はないと考えられる。
Spectre: 少なくともIntelおよびAMDのプロセッサ製品全般、およびSamsungやQualcommなどのハイエンドモバイルプロセッサを含む、投機
実行機能を持つ様々なプロセッサ。ただし一部の構造が単純な組み込み製品を除く。目安として例えば折り畳みのガラケーは対象外だが
Apple Watchなどは対象に含まれると思われる。
> この脆弱性は待ってれば修正されるのか
既に一部ではパッチが適用済みだが、設定が必要な場合もある。サーバ利用では最大で50%の性能低下が見込まれ、デスクトップでも
システムコールを多用する場合には同様の性能低下が起こることがある。具体的な低下幅は利用形態により大きく異なる。
> それとも対象のCPUを使うのをストップしなければならないのかを知りたい
AmazonとGoogleとMicrosoftとAppleが一斉に仮想マシンの再起動をかけていて、協調して1月第2週に情報公開を予定していて、問題が内々に
対処されていた時期にGoogleが諜報機関に文句を言い出したり、IntelのCEOが株を大量に売り抜けていたり、更に半年近くの時間があっても
対象のCPUリストが出てこなかったりする辺りで察してほしい。