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

ある Anonymous Coward 曰く、

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

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

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

防御策があるんだって

[Anonymous Coward]

INTERNET Watchによると、Adobeが「マイクロソフトが配布しているツールを使用することで攻撃を防ぐことができる」と発表したそうです。

http://internet.watch.impress.co.jp/docs/news/20100913_393450.html [impress.co.jp]

「EMET」は優れもの

[chokkan (40227)]

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

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

Re:「EMET」は優れもの

[Anonymous Coward]

現在提供されているEMETには、GUIの設定画面がついています。基本的には、"Configure Apps"ボタンを選んで実行ファイルを指定するだけなので簡単です。

また、"ITセキュリティのアライ出し "の記事には、要注意です。1点だけ、明らかな誤りがあります。コマンドラインで指定する実行ファイル名は、フルパスまたは、相対パスで指定しないと、エラーが発生します。

Re:

[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の検索のキャッシュに残っている直リンクをでなら取得できるようですが、取得できなくなるのも時間の問題でしょう。
バージョンアップのために、一時的に公開をやめているだけかもしれませんが、気になります。

Re:

[Anonymous Coward]

Enhanced Mitigation Experience Toolkit の公開が再開されましたね。ver.2.0.0.2でGUIの設定ツールをアップデートしたそうです。

Re:

[Anonymous Coward]

ESETを使う場合の注意点

AcroRd32.exeだけでなく、AcrobatReaderのActiveXコントロールをロードしうる、Internet Explorer等にも適用すべし。

次から次へと

[Anonymous Coward]

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

Re:次から次へと

[Anonymous Coward]

>でも他の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で守られています。なのでそれが一番安全です。

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:次から次へと

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

いつまで経っても穴が見つかり続けるAdobeって・・・

Re:

[Anonymous Coward]

> いつまで経っても穴が見つかり続ける
と言って叩かれるのが、

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

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

＃こんだけiPhoneやiPadが普及したら狙われるのは時間の問題だと思う

Re:

[Anonymous Coward]

Appleは、あまりに穴が多すぎるので、使用者に気が付かれることなく乗っ取り、悪用することができるのかもね。

Re:

[Anonymous Coward]

アップルを入れるなら、同じUNIX系としてLinuxとかいうOSも入れてあげましょう。

Re:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

>＃こんだけiPhoneやiPadが普及したら狙われるのは時間の問題だと思う
いや、既に、Jailbreakに利用されて、もぐら叩き状態みたいです。

これからは

[Anonymous Coward]

xpsの時代!!

焦らない焦らない

[Anonymous Coward]

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

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

対応策はあると発表しているんだが（Winのみ）

[Anonymous Coward]

cnetの記事で
http://japan.cnet.com/news/service/story/0,3800104747,20419900,00.htm?... [cnet.com]
EMET 2.0で対応可能とか有るんだけれどちゃんとした日本語解説記事がないし
日本語版も無いようなのでかなり不安なのだがどなたか教えてくれませんか？

なぜコールスタックとデータスタックを分けない

[Anonymous Coward]

できればCPUに分けていただきたいが、
既存のCPUでも、Cコンパイラ側で分けること、できますよね。
なぜ、やらないのだろう。
何か、できない理由があるのだろうか。

Re:なぜコールスタックとデータスタックを分けない

[saitoh (10803)]

コールスタップポインタとデータスタックポインタと二つSPが必要になって、レジスタ割り当てを圧迫するから、かなぁ？？ サブルーチンコール/リターンも所要命令数が増えて遅くなりそうだし。

Re:

[Anonymous Coward]

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

Re:

[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管理の)スタックに

Re:

[Anonymous Coward]

レジスタに関して言えば、x86だとスタック関係のレジスタはESPの他にEBPがあります。
CPUがハードウェア処理してくれるわけではありませんが、CコンパイラはEBPをスタック上のデータの位置を示すのに使ってますよね。

Re:

[Anonymous Coward]

単に伝統的にスタック領域が単一だっただけですね。ABIとして、スタック領域が単一であることを前提としているので、既存のモジュールと互換性がなくなっちゃいます。確か、CPUメーカーが出しているソフトウェアガイドラインのレベルでスタック領域が単一であることを前提としていたはずです。もっとも、外部インタフェースのみ、コールスタックとデータスタックを分けるという手もあるが、セキュリティで問題になるのは、この外部インタフェース部分なので、無意味です。
スクラッチで、OSやライブラリ、APIのレベルから新規に作るならともかく、現実的には無理です。