パスワードを忘れた? アカウント作成
254581 story
セキュリティ

Adobe Reader および Adobe Acrobat に新たな zero-day exploit 26

ストーリー by reo
ざっくざく 部門より

ある Anonymous Coward 曰く、

Adobe は米国時間 8 日、Adobe Reader および Adobe Acrobat の脆弱性を突いた新たな zero-day exploit が発見されたと発表した (Adobe Security bulletin: APSA10-02ZDNet の記事本家 /. 記事より) 。Adobe は解決にむけて取り組んでいるとのことだが、現時点では対応策はないとのことだ。

影響を受けるのは Adobe Reader 9.3.4 以前のバージョンの Windows 版、Macintosh 版、そして UNIX 版、そして Adobe Acrobat 9.3.4 以前のバージョンの Windows 版および Macintosh 版。この脆弱性を悪用すればシステムをクラッシュさせ、攻撃者によってシステムが制御される可能性もあるとのこと。既にこの脆弱性を突いた攻撃ケースも報告されているという。

なお、この脆弱性を突いた攻撃のサンプル PDF はマルウェアのサンプルを集めた contagio にて公開されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2010年09月13日 12時46分 (#1824378)
    INTERNET Watchによると、Adobeが「マイクロソフトが配布しているツールを使用することで攻撃を防ぐことができる」と発表したそうです。

    http://internet.watch.impress.co.jp/docs/news/20100913_393450.html [impress.co.jp]
    • by chokkan (40227) on 2010年09月13日 16時03分 (#1824516)

      「Enhanced Mitigation Experience Toolkit 2.0(EMET)」は優れものツールですが、コマンドラインベースです。「Fix it」のようにボタン一つで設定変更とはいかないので、一般のユーザーにはハードルが高いかもしれません。

      EMETについては、こちらの記事が分かりやすいです。つITセキュリティのアライ出し [mycom.co.jp]

      親コメント
      • by Anonymous Coward on 2010年09月13日 17時23分 (#1824568)
        現在提供されているEMETには、GUIの設定画面がついています。基本的には、"Configure Apps"ボタンを選んで実行ファイルを指定するだけなので簡単です。

        また、"ITセキュリティのアライ出し "の記事には、要注意です。1点だけ、明らかな誤りがあります。コマンドラインで指定する実行ファイル名は、フルパスまたは、相対パスで指定しないと、エラーが発生します。
        親コメント
        • by Anonymous Coward
          「Enhanced Mitigation Experience Toolkit 2.0(EMET)」なんですが、ver.2.0の後に、ver.2.0.1が公開されまして、その後、2010/09/14 15:53現在、Microsoft Download Centerから隠蔽されています。Googleの検索のキャッシュに残っている直リンクをでなら取得できるようですが、取得できなくなるのも時間の問題でしょう。
          バージョンアップのために、一時的に公開をやめているだけかもしれませんが、気になります。
          • by Anonymous Coward
            Enhanced Mitigation Experience Toolkit の公開が再開されましたね。ver.2.0.0.2でGUIの設定ツールをアップデートしたそうです。
    • by Anonymous Coward
      ESETを使う場合の注意点

      AcroRd32.exeだけでなく、AcrobatReaderのActiveXコントロールをロードしうる、Internet Explorer等にも適用すべし。
  • by Anonymous Coward on 2010年09月13日 11時51分 (#1824335)

    いいかげん疲れたし飽きた。
    でも他のPDFビューワーにしても調べたら穴がいっぱいあるんだろうなあ。

    • Re:次から次へと (スコア:3, 参考になる)

      by Anonymous Coward on 2010年09月13日 13時59分 (#1824436)

      >でも他のPDFビューワーにしても調べたら穴がいっぱいあるんだろうなあ。
      脆弱性の無いソフトウェアは無いので、多段防御するしかありません。

      にしても、Windowsは互換性を優先しすぎて悲惨ですね。ASLRで安全にするためには依存する全てのバイナリに/DYNAMICBASEが必要で、スタックプロテクタを有効にするためにはバイナリ毎に/GSが必要で、多段防御されているソフトウェアなんて一握り。斜め読みですが、今回のAdobeの件もスタックのバッファオーバーフロー [secunia.com]とicucnv34.dllのアドレスがランダマイズされていない [blogspot.com]のが原因とのことだし。
      UbuntuはFedoraはほぼ全てのソフトウェアでASLRやスタックプロテクタが有効になっています。
      Mac OS XでもASLRやスタックプロテクタは標準で有効ですが、ダイナミックリンカが再配置されないらしい [mycom.co.jp]。何という片手落ち。

      とりあえず、Ubuntu上でAdobe Readerの全ての動的ライブラリのアドレスがちゃんとランダマイズされているか確かめてみました。
      $ LD_LIBRARY_PATH=/opt/Adobe/Reader9/Reader/intellinux/lib/ ldd /opt/Adobe/Reader9/Reader/intellinux/bin/acroread > a.txt
      $ LD_LIBRARY_PATH=/opt/Adobe/Reader9/Reader/intellinux/lib/ ldd /opt/Adobe/Reader9/Reader/intellinux/bin/acroread > b.txt
      $ diff -U 8 a.txt b.txt | grep ^\ ;
      大丈夫のようですが、32bitのASLRは弱いので総当たりで回避できるはず。

      スタックプロテクタ付きでビルドされているかも調べてみました。
      $ nm -D binary | grep __stack_chk_fail
      Adobeのバイナリはほぼスタックプロテクタが有効になってないですね。-fno-stack-protector付きでビルドされているようです。ダメだこりゃ。

      Ubuntu上での標準PDFリーダーのEvinceはASLRやスタックプロテクタに加え、強制アクセス制御のAppArmorで守られていますし、FedoraでもSELinuxで守られています。なのでそれが一番安全です。

      親コメント
      • by Anonymous Coward

        とりあえずサンドボックスで動くというChromeのPDF Viewerを使おうと思ったんですが、PDFのリンクを踏んだときだけ自動的にChromeで開くようなFirefox拡張ってないですかね。
        # 某所で同じ質問をしたらGoogle Docsで開く拡張を勧められました。なるほどその手もあったか。

      • by Anonymous Coward

        コンパイルし直したものが新しい技術を取り入れてるって当たり前
        /GSを-fstack-protector-allに読み代えたって同じじゃん

    • Re:次から次へと (スコア:1, 参考になる)

      by Anonymous Coward on 2010年09月13日 12時24分 (#1824354)

      Sumatra PDF [kowalczyk.info]はどうでしょうか?
      低機能なので、穴が少なそうです。
      1.1から日本語が文字化けしにくくなっています [wolfish.org]ので、便利に使えますよ。
      一次配布サイトが怪しすぎるという人には、Sumatra PDF Portable [portableapps.com]もあります。

      他に、Google Docs Viewerで開くアドオンもFirefoxやChromeなどには各種ありますから、そういうのも良いですね。

      親コメント
    • by Anonymous Coward
      いつまで経っても穴が見つかり続けるAdobeって・・・
      • by Anonymous Coward
        > いつまで経っても穴が見つかり続ける
        と言って叩かれるのが、

        (過去)マイクロソフト→(現在)アドビ→(未来)アップル

        なんじゃないかなぁ、と。

        #こんだけiPhoneやiPadが普及したら狙われるのは時間の問題だと思う
        • by Anonymous Coward
          Appleは、あまりに穴が多すぎるので、使用者に気が付かれることなく乗っ取り、悪用することができるのかもね。
        • by Anonymous Coward
          アップルを入れるなら、同じUNIX系としてLinuxとかいうOSも入れてあげましょう。
          • by Anonymous Coward

            それを言うなら*BSDだと思うが、当面は比較的安心でしょう。

            10年後とか考えると、若手(?)がLinux系に流れすぎてメンテナ不足…なんてのが危惧されるが。

        • by Anonymous Coward
          >#こんだけiPhoneやiPadが普及したら狙われるのは時間の問題だと思う
          いや、既に、Jailbreakに利用されて、もぐら叩き状態みたいです。
  • by Anonymous Coward on 2010年09月13日 11時54分 (#1824337)
    xpsの時代!!
  • by Anonymous Coward on 2010年09月13日 12時30分 (#1824361)

    もう、他のリーダーに乗り換えて久しいのでどうでもよくなってます。
    こういうニュースがあると、Apple vs Adobeの話が再燃してきたりするので
    それもそれで、もうお腹いっぱいです。

    Adobeもどうせ、脆弱性があるんだったら
    Googleくらい速度にこだわってくれてもいいと思うんですけどね。
    遅いし、弱いしじゃ弁護ができません・・・

  • by Anonymous Coward on 2010年09月13日 12時45分 (#1824377)
    cnetの記事で
    http://japan.cnet.com/news/service/story/0,3800104747,20419900,00.htm?... [cnet.com]
    EMET 2.0で対応可能とか有るんだけれどちゃんとした日本語解説記事がないし
    日本語版も無いようなのでかなり不安なのだがどなたか教えてくれませんか?
  • by Anonymous Coward on 2010年09月14日 4時53分 (#1824849)
    できればCPUに分けていただきたいが、
    既存のCPUでも、Cコンパイラ側で分けること、できますよね。
    なぜ、やらないのだろう。
    何か、できない理由があるのだろうか。
    • コールスタップポインタとデータスタックポインタと二つSPが必要になって、レジスタ割り当てを圧迫するから、かなぁ?? サブルーチンコール/リターンも所要命令数が増えて遅くなりそうだし。
      親コメント
      • by Anonymous Coward

        どんなに素晴らしいセキュリティ対策を考案しても互換性が保てなければWindowsでは絵に描いた餅だし。
        EMETで設定できるSEHOPも本来は既存のアプリに未変更で適用できる対策として考案されたのに、CygwinやSkype等で不具合出まくりなのでDEPやASLRと大差ないアプリケーションごとのホワイトリストになってしまいましたとさ。

        • by Anonymous Coward
          OSのAPIや、既存ライブラリを呼ぶときには、互換性のために、データをスタックに積まないといけませんが、
          callerとcalleeが両方ともアプリケーションの中の関数なら、カスタムのcall規約を使うことが出来るハズですよ。

          たとえば酷いコードの例として
          void foo(char *a, char *b) {
                  char hoge[100] ;
                  sprintf(hoge, "%s and %s", a, b) ;
                  doSomething(hoge) ;
          }
          こんなのがあったとき、(sprintfを使うな!というのは、とりあえず、おいといて)
          関数の引数aとbを(CPU管理の)スタックに
      • by Anonymous Coward
        レジスタに関して言えば、x86だとスタック関係のレジスタはESPの他にEBPがあります。
        CPUがハードウェア処理してくれるわけではありませんが、CコンパイラはEBPをスタック上のデータの位置を示すのに使ってますよね。
    • by Anonymous Coward
      単に伝統的にスタック領域が単一だっただけですね。ABIとして、スタック領域が単一であることを前提としているので、既存のモジュールと互換性がなくなっちゃいます。確か、CPUメーカーが出しているソフトウェアガイドラインのレベルでスタック領域が単一であることを前提としていたはずです。もっとも、外部インタフェースのみ、コールスタックとデータスタックを分けるという手もあるが、セキュリティで問題になるのは、この外部インタフェース部分なので、無意味です。
      スクラッチで、OSやライブラリ、APIのレベルから新規に作るならともかく、現実的には無理です。
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...