XpdfとAcrobat Readerにセキュリティホール、任意のコードを実行 21
ストーリー by Oliver
ハイパーリンクの光と影 部門より
ハイパーリンクの光と影 部門より
k3c 曰く、 "Xpdfのバージョン2.02pl1が公開されている。特定の文字をURLリンクに含めることで、system()関数を呼び出したときに任意のコマンドを実行されてしまうというセキュリティホールを修正している。PDFビューアーのみに発生する問題であり、コマンドラインアプリケーションは影響を受けない。バージョン2.02に適用可能なパッチファイルも公開されている。
Full-Disclosureメーリングリストへの投稿やRed Hat LinuxのErrataによれば、このセキュリティホールは2.02より前のバージョンから存在していたようだ。PDFファイル中のハイパーリンクを何気なくクリックすると任意のコマンドを実行されてしまうという悪質なバグなので、全てのXpdfユーザーが、パッチを適用済みのバージョンにアップグレードするか、PDFファイル中のハイパーリンクを安易にクリックしないように対処する必要があるだろう。"
続いてk3c 曰く、 "掲載を待っている間にCERT Advisoryが出ました。Adobe Acrobat Reader for UNIXにも同じセキュリティホールがあったそうで、修正済の新バージョン5.07 for Linux, Solaris, HP/UX and AIXがリリースされています。"
対処方法 (スコア:5, 興味深い)
安全なWebブラウザの呼び出し機構が用意されている、という方が
少なくともアプリケーションを作る側には嬉しいと思います。
Windowsだとこの辺はよく整備されているが、UNIX系だと、例えば
GNOMEやKDE等のデスクトップ環境が面倒を見るのでしょうか。
デスクトップ環境の差と、ブラウザの差と、それぞれ吸収して
くれる機構があるとさらに有難い。
Re:対処方法 (スコア:2, 参考になる)
GNOMEにこういうレベルの関数 [gnome.org]はあります。
(gnove-vfsは、ブラウザの差というか、プロコトルの差を吸収する
ライブラリで、HTTPやFTP等々を透過的に扱えます)
Re:対処方法 (スコア:1)
結局のところoltioさんの仰っていることは、共通に一種の「関連付け」を
行なう機構が必要だ、ということですよね。
~~~
Windowsでも、もうちょっと便利だといいなぁと思ったことはあります。
明示的にどのブラウザで開くか指定しない限り、特定のサイトは
特定のブラウザで開いてくれるとか。普通に必要だと思うんですが
現状手でURLをコピーしている感じですよね。
結局一つのアプリケーション上でしか動かない、ブラウザ選択用の
dllを書いてしまいました。しかもShellExecuteを使うのでブラウザ毎に
対応が必要だったり。
リリースするのはいいんだけど… (スコア:2, 参考になる)
Help -> About Acroba Reader...が
Linux版では5.0.6でも5.0.7でも5.0.5と表示されます。
Re:リリースするのはいいんだけど… (スコア:1)
Re:リリースするのはいいんだけど… (スコア:0)
Re:リリースするのはいいんだけど… (スコア:1)
で、Weblink Plug-in のバージョンを見ると5.0.7に上がっています。
同じ穴 (スコア:0)
# 最近そういうニュースが耐えないので、つい疑ってしまうのですが
GPdfにも同様の脆弱性あり (スコア:2, 参考になる)
「xpdfのコードをパクった」GPdfにもまったく同じ、
脆弱性を含んだコードが含まれています。
最新の0.103で確認しました。
Re:同じ穴 (スコア:0)
Re:同じ穴 (スコア:1, 参考になる)
21世紀にもなってこんなのが見つかるとは泣けて来るよな。
実行環境側での対策 (スコア:2, 参考になる)
何十年たって何世紀になっても、人為的な誤りは無くならないでしょう。
だからこそ、OSやインタプリタという実行環境側の枠組みで
安全性を保障する事が必要だし、それについて試行錯誤が
なされ、発展していくのは望ましい流れだと思います。
現状のように、ひたすら補修をし続けないとほんとにやばい、
というのは、工学という見方からしてもあまり、健全ではないような。
# …というような話を聞きました ;)
Re:実行環境側での対策 (スコア:2)
成り立っているという見方もあると思います.
次々と不完全な製品をリリースし続けることが
将来の新たな需要につながっている訳です.
ものすごく使いやすくて,バグがない製品が一度できたら
ソフトウェア産業は そこで おしまいで,
ソフトウェア工学も不要になっちゃいます.
言い換えると,
これからもずっと 試行錯誤は続くのだと思います.
Re:実行環境側での対策 (スコア:1)
(snip)
> これからもずっと試行錯誤は続く
ソフトウェア産業に限らず、資本主義や学問というモノ自体が
そういう面を持つのでしょう。
失礼かもしれませんが、内容が一般的過ぎて
自分には意図が読めませんでした。
自分が書いたコメントは筋違いでした [srad.jp]が、
「ものすごく使いやすくて,バグがない製品」が
存在すべきとも、存在するようになるだろうとも
書いた覚えはないです。
Re:実行環境側での対策 (スコア:0)
>将来の新たな需要につながっている訳です.
世の中のニーズは変わってきていないの?
ビジネスのやり方は変わってきていないの?
あなたの環境は変わってきていないの?
いくら高品質でも、もうおしまいっていうコトは
あり得ないと思う。
Re:実行環境側での対策 (スコア:1)
# なお,$SAFE==3ではuntaintが禁止されているのでsystemに渡すことができず,$SAFE==4ではsystemが禁止されている。
irb(main):002:0> Thread.start { url='http://`date`/'.taint; $SAFE=1; system url.untaint }.join
sh: http://2003年: そのようなファイルやディレクトリはありません
=> #<Thread:0x402af2f0 dead>
Re:実行環境側での対策 (スコア:1)
パッチの内容を見ないまま、元コメントの方の「フィルタリング忘れ」と
いう単語を「サニタイズのし忘れ」と読んでしまいました。以後気をつけます。
ということで、今回の件から得られる教訓は…えーと…
「サニタイズとは、
『危険なものを取り除くこと』ではなく
『安全なもののみ残すこと』」
という原則、くらいでしょうか。
Re:実行環境側での対策 (スコア:1)
人間によるこまめなチェックと補修が必要なんです。
工学という見方とかじゃなくって、そういうのは原理的に不可能。
チューリングの時代からわかってることです。
#だったんじゃないかな~
Re:実行環境側での対策 (スコア:2, 参考になる)
完全にできる、なんて思ってないし、書いていないです。
別コメントでもあるように、例えばRubyでやってるのは
「人間が明示的に『安全』だと言わないものは危険とみなす」
というだけで、間違って「安全」としたらそれで終わりです。
(今回の件もそうですね)
Cコンパイラがカナリアを仕込む話にも「完璧」なんて
言葉はなかったはずですし、どこまでいっても
インタプリタやコンパイラ自体の誤りもあるでしょうし。
ただ、OSなり何なりで一段階置くことで、人間の
目玉以外の層でのチェックができればだいぶ違う、
と(感覚的には;)思うのですが、どうでしょうか。
Re:実行環境側での対策 (スコア:1)
私が元コメントを誤解したようです。
言い訳するならば「ひたすら補修をし続けないとほんとにやばい」というのが気になったんです。
「工学的に健全なのは、補修しなくても良い方法を考えること」みたいなのに感じて。
Advisoryじゃなく (スコア:0)