Adobe Readerにサンドボックス技術を実装へ 34
ストーリー by soara
ハッチ・ポッチ・パッチ 部門より
ハッチ・ポッチ・パッチ 部門より
あるAnonymous Coward 曰く、
Adobe Readerの次期メジャーリリースではセキュリティの向上を目指し、サンドボックス技術が実装されるとのこと(CNET Japan、本家/.)。
このサンドボックス技術「Protected Mode」は Google Chromeのサンドボックスや Microsoft Office 2010のProtected Viewing Modeに似たものとなるそうで、悪意あるハッカーによる攻撃を阻止することが目的とのこと。サンドボックス技術実装当初はまずWindows 7、Windows Vista、Windows XP、Windows Server 2008および Windows Server 2003において「書き込み」コールを隔離するという。
Adobeのセキュリティ・チーフ Brad Arkin氏曰く、この技術が実装されればコンピュータにマルウェアをインストールされたり、ファイルシステムやレジストリを変更しようとする攻撃のリスクを軽減できると考えているとのこと。
さらに将来的には「read-only」のアクティビティに対してもサンドボックス技術を導入し、コンピュータ上の情報を得ようとする攻撃からもユーザを保護する計画とのことだ。
本質的な問題 (スコア:5, すばらしい洞察)
Adobe製品（特にAcrobat系）の本質的な問題は、どちらかというと「パッチを当てるだけでOSの再起動を要求してくる」ことではないでしょうか。作業中にこれをやられるとストレスが溜まり、それを覚えてしまったユーザーはアップデートを故意に回避するようになってしまう、と。
その結果、セキュリティ的に問題があるバージョンのユーザーが残るため攻撃の成功率が上がり、「これは攻撃しやすい」という評判が立ってさらに穴を探される、という悪循環に陥ってる気がします。
ユーザーに不便を強いないようなアップデートの方法を用意するだけで結構、話が変わってきそうに思えるのですけれどもね……。
Re: (スコア:0)
いつのバージョンからだったか、インストールでは要求されなくなったので「ああ、進化したなあ」と思ったもんです。
アップデートでももはや技術的にはReader自身とプラグイン先ブラウザ等の再起動で済むようになってると思うのですが、何がOSを再起動させようとしているんでしょうね？どこか深いところに食い込んでるのでしょうか...
Re: (スコア:0)
関連プロセスを登録しようとしますよね。
またおっきくなるのか (スコア:3, すばらしい洞察)
たかがビューアで現状300MB近くも取るってのが納得いかん。7の頃は数十MBで済んでたのに、一体今は何でこんなにいるのか。
HDDが少なくてAdobe Reader入れてないのでAC
Re: (スコア:0)
Re:またおっきくなるのか (スコア:2, 興味深い)
Foxit Readerは悪くない・・・というか素晴らしいんだけどセキュリティ面が心配なので私は使ってない。
だって真っ当にPDF対応し過ぎ。
むしろJavascript関連やら外部コマンド起動やら何やら、全く対応しないで
表示のみの機能しかないViewerとかがいいかな。
# 入っているけどOFFにもできるよ、というのは絶対抜け道があると思うから
Re:またおっきくなるのか (スコア:1)
そんなあなたにSumatra PDF [kowalczyk.info]。
Re: (スコア:0)
鏡を見ろ (スコア:0)
Re:鏡を見ろ (スコア:1, 興味深い)
「東アジアの方々はPDF1.5じゃ足りないとみている」ことを前提とした主張かな?
この前提は真なのかな…?
つーか、3Dとかプログラミングとかわけわからん「進化」をしているからだとおもってた。
Re:鏡を見ろ (スコア:1, 参考になる)
ディスク消費量が大きいのは「修復」のためにセットアップファイルをまるまる保持(約135MB)しているせいですね。
確かに日本語版は小塚フォントを抱えているので13MBくらい余計に消費していますが。
サンドボックス地獄 (スコア:2)
Chrome上で実行したら、サンドボックス上で動くAdobeReaderがサンドボックスを提供することになるのか。
これでこけたら、砂上の楼閣ですね。
Re:サンドボックス地獄 (スコア:3, 興味深い)
今のところプラグインはサンドボックス外で動くので(今回のAdobe Readerのように)プラグインが独自にサンドボックスを提供しない限りサンドボックスでは動きません。
この問題を解決するためにサンドボックス内で動かせるプラグイン用のAPIをGoogleが提唱していて、それに対応したのがChromeの内蔵FlashやらPDFビューアーやらです。
いや、だから、 (スコア:1)
＞将来的には「read-only」のアクティビティに対してもサンドボックス技術を導入
要らないアクティビティを省くという方向に、何故考えが及ばないのか
Re:いや、だから、 (スコア:1)
本当に、機能を限定した Adobe Reader Lite を出してくれれば良いんですよね。
# 「機能を削るためのコストをかけているので、Liteは有料ね」と言って、皆が買ってくれれば、明日にでも作ってくれるかも知れません。
# …が、Adobe の価格設定だと、9,800円とかかな…。
Re: (スコア:0)
確か、Adobe Reader LEだったかな
私の携帯（Docomo）に入っていました
ほんとに必要最低限って感じで、これがWindowsででたらなぁ
なんて使う度に思ってしまいます
Re: (スコア:0)
モバイルデバイスのメモリ制限なのか
一定サイズ以上のpdfが読めないのが難点。
そこだけ直してくれたらLEでもいいや。
Re: (スコア:0)
＞要らないアクティビティを省くという方向に、何故考えが及ばないのか
あなたの知らないどこかに需要があるからでしょう。
簡単に省けと言うけど、一旦載せてしまった以上代替案なしにその機能を省くのは難しいことです。
Re: (スコア:0)
今回の変更で、「書き込み」コールを隔離するわけですよね。read-only のアクティビティというのは、要するに「書き込み」コール以外の残ったアクティビティ全部でしょう。中には不要なアクティビティもあるかもしれないけど、残り全部を省けるってことはないのでは。
もう、 (スコア:0)
.NETかJavaで実装しろよ...
穴開きすぎQuickTimeのAppleも。
Re:もう、 (スコア:2, おもしろおかしい)
１、移植性が損なわれる。
２、C/C++の莫大な遺産を活用できない。
＃そんなあなたにXPS。
Re: (スコア:0)
でも、「AdobeReaderに気を付けるくらいならXPSでいいじゃん」って層もそれなりには実在するんですよね。
Re:もう、 (スコア:1)
（QuickTimeの脆弱性16件修正 [itmedia.co.jp]とか）
Appleは潰れない程度にマイナーな存在でいて欲しいです。
周辺機器が対応していない程マイナーになっては困りますが、ウィルスやワームの標的となる程メジャーでも困る……
notice : I ignore an anonymous contribution.
Re: (スコア:0)
言語の性能の差がセキュリティの絶対的な差でないことを思い知らせてやる!!
(とか
Re: (スコア:0)
でも、Microsoftが「Windowsのアプリは.NET Frameworkベースのものしか認めない、開発ツールはVisual Studio限定だ」とか言い出したら、Appleは全力で反発するんだろうなぁ
＃お前はiPhone関連で何してるんだ、と言われても無視するだろうし
で、 (スコア:0)
Javascript(ブラウザじゃなくてリーダーの)を有効にしないと見られない、JIS規格のPDFとかどうなるんですかね？
プラグイン (スコア:0)
インストールすると各種ブラウザ用のプラグインを勝手に入れられるのが鬱陶しくて仕方がない
インストーラで入れるか入れないかの選択すらできないし…
これがリスクを大幅に高めてるような気がしてならない
Re: (スコア:0)
Re: (スコア:0)
AppleがiPhone4に搭載したアレですか……。