アカウント名:
パスワード:
IBMの元記事 [securityintelligence.com]の意図としては、Edgeで使われているPDFライブラリが①JavaやFlashのような汎用のVM(.NET Framework)で動作すること、②ライブラリなので親と同じプロセスで動くこと、の2点から、新しい攻撃の標的として狙われる可能があるよ、と言っているようです。
「現段階では、多重の攻撃緩和機構のために、EdgeのPDFを攻撃するのは高くつく」とも書いているので、別に具体的な攻撃策があるわけではなく、あくまで一般論のレベルで「いかにも狙われそうなアーキテクチャじゃないか?」と言いたいようです。
一般論として考えれば、確かに狙われそうな設計になっている気はします。一方で、Silverlightなどはそれほど脆弱性が多かったという話は聞きませんので、結局は.NET Frameworkのクオリティ次第でしょうね。
そういや、EdgeブラウザーやWindowsストアアプリは低権限化+runtime brokerでサンドボックス化されているって聞きましたけど、このWinRT PDFは違うのですか? 親と同じプロセスならこちらもサンドボックス動作になりそうな気も…。
サンドボックス化されていれば良いのだが 部門より
Firefox の PDF.js も似ているところがありますね(Firefoxに深刻な脆弱性、Mozillaが更新を呼びかける [security.srad.jp])今は javascript も VM ですし、WebGL で GPU も触れるし、リッチにはなりましたがセキュリティの担保は大変になっている気がします。(何となく不安という理由で WebGL は無効化しています……)
MSはまさに、WebGLにGPUを触らせるのが不安だという主張で、ブラウザへのWebGL実装を見送っていた時期がありました。その後、セキュリティ用のレイヤーを被せてWebGLを実装する方針になったとか…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
元記事の意図 (スコア:1)
IBMの元記事 [securityintelligence.com]の意図としては、Edgeで使われているPDFライブラリが
①JavaやFlashのような汎用のVM(.NET Framework)で動作すること、②ライブラリなので親と同じプロセスで動くこと、の2点から、
新しい攻撃の標的として狙われる可能があるよ、と言っているようです。
「現段階では、多重の攻撃緩和機構のために、EdgeのPDFを攻撃するのは高くつく」とも書いているので、
別に具体的な攻撃策があるわけではなく、あくまで一般論のレベルで「いかにも狙われそうなアーキテクチャじゃないか?」と言いたいようです。
一般論として考えれば、確かに狙われそうな設計になっている気はします。
一方で、Silverlightなどはそれほど脆弱性が多かったという話は聞きませんので、結局は.NET Frameworkのクオリティ次第でしょうね。
Re:部門名 (スコア:0)
そういや、EdgeブラウザーやWindowsストアアプリは低権限化+runtime brokerでサンドボックス化されているって聞きましたけど、このWinRT PDFは違うのですか? 親と同じプロセスならこちらもサンドボックス動作になりそうな気も…。
サンドボックス化されていれば良いのだが 部門より
Re: (スコア:0)
当然、そこから呼ばれる WinRT PDF もサンドボックスの中。
Re: (スコア:0)
Firefox の PDF.js も似ているところがありますね(Firefoxに深刻な脆弱性、Mozillaが更新を呼びかける [security.srad.jp])
今は javascript も VM ですし、WebGL で GPU も触れるし、リッチにはなりましたがセキュリティの担保は大変になっている気がします。
(何となく不安という理由で WebGL は無効化しています……)
Re: (スコア:0)
MSはまさに、WebGLにGPUを触らせるのが不安だという主張で、ブラウザへのWebGL実装を見送っていた時期がありました。
その後、セキュリティ用のレイヤーを被せてWebGLを実装する方針になったとか…。