Adobe の「ゼロデイ脆弱性」の存在、8 ヶ月前には分かっていて誤診断 15
ストーリー by reo
まあそういうこともあらぁな、ですまないのが大変 部門より
まあそういうこともあらぁな、ですまないのが大変 部門より
あるAnonymous Coward 曰く、
先日発見された Adobe Flash の脆弱性について、対策が発表されていない 0-day 攻撃だと思われていたものが (ITmedia News の記事)、Adobe のセキュリティチームはこの問題について、8 ヶ月前から存在を知っていたそうで、セキュリティの問題ではなく、「データ損失・破壊の問題」としていたそうだ (ZDNet Japan の記事より) 。
Adobe Flashの脆弱性だよーん (スコア:3, 参考になる)
＞先日発見されたAdobe Readerの脆弱性について、
Adobe Flashにゼロデイ攻撃、Adobe Readerにただちに処置を [zdnet.com]によれば、
なおこの悪意あるFlashオブジェクトを含むPDFは現在Trojan.Pidief.G [symantec.com]として検出可能という。
【参考】セキュリティホールmemo : ■ Potential Adobe Reader, Acrobat, and Flash Player issue [ryukoku.ac.jp]
モデレータは基本役立たずなの気にしてないよ
Re: (スコア:0)
先日の (スコア:2, すばらしい洞察)
Linuxのゼロデイ [srad.jp]もそうでしたが、DoSだと判断するだけならまだしも、だから直さないと安易に結論付けることのリスクが軽視されすぎですね。
「任意コード実行は出来ない」と言い切れるほど自信を持つのは結構ですが、だったらそもそもそのバグはどうして入ったのかと。
Re:先日の (スコア:1, 参考になる)
禿同。
「データ損失・破壊の問題」って、セキュリティと同程度に問題だと思います。
修正の優先度を下げる理由にはならない、と思うのだが…。
もしかして、「この修正の優先度が低くなるほど、flashには深刻な問題が山積み」ということでしょうか。
AdobeのPDF製品全般の品質について (スコア:2, 興味深い)
はっきり言ってAdobe製品はエラー処理がズサンだと思うことがある。
PDF出力するプログラムを書いていて、出力したPDFのデータ形式にミスがあると、
大抵は怪しげな動きをしたりクラッシュして、役に立つ警告やエラーを表示してくれない。
各所でアサーションして論理エラーを防止するような措置をとっていないどころか、
エラーが発生したら、エラーをつかまえて通知するのではなくて、
なかったことにして処理を続行するのがAdobeの方針なんじゃないかと思える。
あるいはテストやデバッグのしやすさを考えずに開発してしまったので、
開発チーム自身やる気をなくしているとか。
Re:AdobeのPDF製品全般の品質について (スコア:2, すばらしい洞察)
ファイルが破損していても部分的にでも読めたほうがよいと思う。
Re:AdobeのPDF製品全般の品質について (スコア:1)
Acrobat Pro で PDF ファイル自体を編集中に強制終了が発生し、再度起動すると編集中だった PDF を復旧するかどうか確認してくるのですが、一度として編集開始時点の PDF にすら戻った事がないのですが。
例えば「フォーム項目が全部消失」「JavaScript のコードが一部だけ編集されているが、大半が吹き飛んでいる」「そもそも元の原稿データの大半が消えている」といった感じで。
その挙句、正常に終了を選択してもゾンビプロセス化するのが日常茶飯事な訳で、まともなエラー処理なんてとてもできているとは思えないですね。
元のコメントも「PDF の読み取り」ではなく「PDF 編集」ですので、「少々崩れようが」なんてのは論外です。
さらに言えば Adobe 自身はイントラネット内での Adobe Reader をクライアントとした申請系などの「お金になる」部分に注力していますので、その点からも「多少エラーがあっても読める事が重要」なんて考え方はちょっと問題があるように思います。
Adobe Reader シリーズ全般ではなく、あくまでも PDF 製品全般 (Acrobat ファミリーや LiveCycle ファミリー等) の話として考える方が適切でしょう。
Re: (スコア:0)
そのような意図があるとは思えません。
Adobe Readerは、あるページに破損した画像が1つあるだけで、
表示できないコンテンツがあるといった意味不明なエラーダイアログが出て、
ページ全体が表示されないといったことが起こります。
「レイアウトが少々崩れようが読めることが重要」なら、
壊れた画像だけが見えない状態にならないとおかしいです。
そもそも、クラッシュしたり、バッファオーバーフローすることを放置する言い訳にはならないと思いますよ。
Re: (スコア:0)
不完全な文書が、正しい情報を伝えてくれる保障はない。
画像が壊れただけだから表示しよう、レイアウト情報が正しくないだけ
だから表示しよう。
さてその文書の文章は正しいなんて思えるかな？
それ以前に、すぐに誤動作起こすアプリが表示してる文書が正しいのか、と
言われたら反論できない。
Re: (スコア:0)
クラッシュしてるからそれ以前ですね。
Re: (スコア:0)
どうしてすばらしい洞察がついているんだろう…。
> 文書なのでエラーで止まることよりもレイアウトが少々崩れようが読めることが重要。
> ファイルが破損していても部分的にでも読めたほうがよいと思う。
それはその方が良いけれど、それを実現するのは文書にエラーがあっても正常に
エラー処理が行われるプログラムであって、クラッシュするような問題をスルーしていいわけがない。
まあユーザー側の希望としては色々かもしれないけれど、作る側の理屈で言えば
エラー(文書構造ではなく実行時のエラー)を放置して動くならそれでいいという
姿勢はまともなものじゃない。
アナログ体質 (スコア:0)
Adobeってデザイン屋さんで、あまりソフトウェア開発企業としての下地が少ない気がする...。
「ソフト屋なのにアナログ体質」って感じ。
クリエイターの直感を最大限活かせるようにしていたり、デザイン作業のデジタル化以前の知識をそのまま使えるようにしているなど旧来のデザイナをPCに移行させる分には良い(し、事実支持された)んだけど、その分他のジャンルのソフトを普通に使える人にとってAdobe習得は逆に楽じゃない。
そしてソフトウェアとしてはあり得ないくらいめちゃくちゃだし、紙に出さない画面上で完結するデザイン仕事にも弱い(CS3ですら旧Adobeものはダメダメ)...
# 旧Macromediaにはあまりあてはまりません。合併はその補完もある程度あてにしていたような感じ。
(頭が)おかしいと思う点 (スコア:1)
バグ?だか脆弱性だか分からんが、そんな前から分かっていたのに
直そうとしなかったというあたりが頭おかしいな。
データ損失とか破壊とか、普通に考えたらセキュリティに
負けず劣らず重要な問題だと思うのだが。
Re:(頭が)おかしいと思う点 (スコア:2, 興味深い)
そのバグに気づいてからはAdobeはプログラムの品質に関しては一切信用していない。
…でも使う。
＃なんで一つのプログラムに同一処理のUnicode版とマルチバイト版が混在するんだ。
＃ファイルオープンAPI選択フラグがUnicodeなのにD&Dファイル名をマルチバイトで取得するんだ。
＃なんでそういう綱渡りの変換を混ぜておいてマルチバイト環境でテストしないんだ。
＃なんでそのバグをメジャーバージョンアップ2つ分も放置するんだ。
＃調べ方がアレだったので報告はしていない・・・が発症者(特にFlash作成者で発症しやすい)は山ほど居るはずだから報告されてるだろうに・・・
Re: (スコア:0)