GNU gzipに脆弱性、1.4リリース 38
タレコミ by Elbereth
Elbereth 曰く、
JVNのJVNVU#188937 GNU gzip における複数の脆弱性経由で知ったが、GNU ProjectのGNU gzip — News: gzip-1.4 released (stable/security)によると、GNU gzip 1.3.14 ～1.3.3 のバージョンに複数の脆弱性があり、修正がされた1.4がリリースされたとのこと。 この記事によると、脆弱性のあるバージョンでは、細工された gzip 圧縮ファイルを処理させることで、サービス運用妨害 (DoS) 攻撃を受けたり、ユーザの権限で任意のコードを実行されたりする可能性がある。また、脆弱性の一つは、64-bitシステム上でのみ影響を受ける模様。 gzip 1.3.3のリリースは2002年3月8日で、1.3.14は2009年10月30日のリリースなので、かなり長期間のものが対象になる。 ※なお、2/5 03時現在でCODEZINEの記事では「2009年10月に公開されたバージョン1.3.3以来の安定版」と書かれていますが、これは1.3.14のことと思われる。
JVN の脆弱性レポートの誤り (スコア:4, 参考になる)
JVN の脆弱性レポート [jvn.jp]の「詳細情報」の項には、
とあり、普通に解釈すれば 32 ビットシステムに影響する脆弱性も見つかったかのように読めるのですが、これはほぼ誤りと言って良いと思います。
gzip 1.4 のリリース案内文 [gnu.org]によれば、 gzip 1.4 で修正されたバグは「32 ビットシステムに影響しない脆弱性」と「脆弱性ではないバグ」の二つであり、 gzip 1.4 での修正内容の中に「32 ビットシステムに影響する脆弱性」はありません。
JVN の脆弱性レポートを読み返すと、「関連文書」の項に CVE-2009-2624 [mitre.org] と CVE-2010-0001 [mitre.org] の二つの CVE 番号が書かれています。 CVE-2010-0001 というのは gzip 1.4 のリリース案内文に書かれている脆弱性です。では CVE-2009-2624 って何?
CVE-2009-2624 は、 gzip 1.3.13 で修正された脆弱性です。たしかにこれは 32 ビットシステムにも影響するので、
という意味だとすれば誤りではないとも言えますが、まあこれは屁理屈の類でしょう。
もちろん、 32 ビットシステムでも gzip を最新のものに更新するに越したことはないと思います。
翻訳の誤り？ (スコア:3, すばらしい洞察)
Re:翻訳の誤り？ (スコア:2, すばらしい洞察)
その辺はスラドと一緒ですね。
Re:翻訳の誤り？ (スコア:4, すばらしい洞察)
JVN の脆弱性レポートもスラッシュドットも「情報入手の取っ掛かりとしてはいいと思いますが、その先の元情報にあたる必要は」ある、というのは同意しますが、間違った脆弱性レポートを鵜呑みにしてそのままタレコミを書いた本人が言うことではないと思います。
Re:翻訳の誤り？ (スコア:1)
気をつけます。
ちょっと補足 (スコア:2, 参考になる)
LZWに関するバグはgzip: (64 bit) Integer underflow by decompressing LZW format files [redhat.com]のものと思われます。
対応するパッチはgzip -d: do not clobber stack for valid input on x86_64 [gnu.org]で、ここには
とありますね。つまり、LZW解凍時のバグが「64-bitシステム上でのみ影響を受ける」方のようです。
（整数演算のアンダーフローが配列参照エラーに繋がり、任意のコードを実行されかねない危険なバグです）
もう一つも同じく解凍時のバグですけど、こちらは
とのことですから、セキュリティーホールにはならないかも。
（DOS / OS/2 / WindowsのFATで圧縮されたもののみで発生？）
Re:ちょっと補足 (スコア:2, 参考になる)
# この程度はちょっと調べれば分かると思うぞ。
Re:ちょっと補足 (スコア:2, 参考になる)
んと、私の示した後者は、それではないように思うのですが……。
タレコミのリンク先（GNU gzip — News: gzip-1.4 released (stable/security) [gnu.org]）にある"gzip -d would fail with a CRC error for some valid inputs."のことで、これはgzip -d would fail with a CRC error... [gnu.org]にパッチがあります。（正式リリースとは若干内容が異なっているっぽいですが）
memcpyでソースとデスティネーションが重複してしまっている状況への対処ですから、これ自体は脆弱性には繋がらないんじゃないかと。
Re: (スコア:0)
> 1.3.5 上で発見され直したはずのバグの再発
gzipってregression防止のためのunit testやってないの?
Re: (スコア:0)
"整数アンダーフロー"でもひっかかるし、そういう言葉があるみたいだな。
mod_gzipとはコードベース別？ (スコア:1)
mod_gzipも同じコードベースからの派生？全然別？
もし同じ脆弱性があるんだったら、wikiとか掲示板みたいに書き換え可能なコンテンツ経由でやられるおそれがあるのでおそろしいな。
Re: (スコア:0, 荒らし)
> 細工された gzip 圧縮ファイル
とあるので、そもそもmod_gzipは関係ないのでは?(圧縮しかしない)
そもそも、apacheだったりwikiの方には、もっと深刻な脆弱性がごろごろしてますから、
そちらの方を心配された方が。。。
Re:mod_gzipとはコードベース別？ (スコア:1)
ああ、そりゃそうですね。>(圧縮しかしない)
短絡的なコメント申し訳ない。
Re: (スコア:0)
ここ数年はかなり安定しているイメージだったんだけど。
clamav (スコア:1)
clamavなどのウイルス対策があだとなって、逆に攻撃されてしまい兼ねませんね。
攻撃を仕込んだ圧縮ファイルを添付したメールを送るだけで攻撃できてしまうし。
Re:clamav (スコア:1, 興味深い)
圧縮ファイルを利用したアンチウイルス製品攻撃なんて昔からあるような・・・
超圧縮したnullとか送りつけるとか。
バージョンの順序 (スコア:0)
「〜」の後のほうがバージョン低いって違和感があるな。
Re:バージョンの順序 (スコア:1)
推敲が足りなかった。
不思議 (スコア:0)
ファイルの圧縮や展開がセキュリティに影響するような状況ってどういう感じなのでしょうか。
イメージとしては、圧縮や展開は単純にデータの繰り返し部分や不合理な部分を置換する作業であって、
不正コードの実行なんかとは無関係に思うのですが。
Re:不思議 (スコア:4, 参考になる)
あと圧縮ではなくアーカイブ系では展開時などにファイルのパーミッション間違えるといった危険もあります。
-- Takehiro TOMINAGA // may the source be with you!
アーカイブ系プログラムの脆弱性 (スコア:4, 参考になる)
・絶対パス名でアーカイブされたファイルを、絶対パス名のまま展開する
という事例がありました。
たしか、Antiny系のトロイの感染手段として一時期猛威をふるっていたような。
Re:アーカイブ系プログラムの脆弱性 (スコア:1, 興味深い)
"../../../../../..・・・/tmp/hogehoge"というファイル名で絶対パスと同様になってしまうというのが過去にあったような。
Re: (スコア:0)
元コメACです。なるほど！ それは危険ですね。想像力が欠如してました。
いつもSecurity Advisoryが出るとただ無意識にアップデートしていました・・・
Re: (スコア:0)
たまに絶対パスで固めたアーカイブをよこす人が。
悪意でないにしても、
クリティカルなファイルを書き換えられる可能性があるので
内容確認してから展開しなくちゃと思ってはいるのですが…。
Re:アーカイブ系プログラムの脆弱性 (スコア:3, 参考になる)
>ぜ、脆弱性なの？！tar は今でもその仕様のままでは？
最近のBSD系のtarやGNUtarは直ってます。
Solarisは知らん。(直ってないような気がする。識者突っ込み希望)
Re: (スコア:0)
Re: (スコア:0, すばらしい洞察)
ライブラリには影響しないのかもしれないけど、httpdのdeflateに使われていたらアップロードされたモノで攻撃が成立するかもしれない。
Re:不思議 (スコア:2, 参考になる)
mod_deflateは圧縮しかしないから関係ない [srad.jp]そうだよ。
どっちもすば洞が付いてるあたり、いかにモデレータが脊髄反射しかしていないかよくわかる。
# そしてこのコメントは脊髄反射でフレームのもとや荒らしにされる予定なのでAC
Re:不思議 (スコア:4, 興味深い)
その昔、Solarisかなんかのアーカイバがワークメモリをゼロクリアせず使ってたところ、
権限チェックをする関係上/etc/passwd(違ったかも)が直前に読み込まれてた領域で、
中身が出力されてしまうセキュリティホールがあったとセキュアコーディングに関する書籍で
読んだ記憶があります。
という訳で、malloc()した領域を未初期化部分までファイル出力しただけで状況によっては
セキュリティホールになりうるので注意が必要ですね。
#ファイル自体は過去の遺物で実際には利用されておらず、パスワード部分もハッシュされた
#状態で格納されていたので直接の実害はなかったとか。
スルースキル：Lv2
Keep It Simple, Stupid!
Re:不思議 (スコア:3, 参考になる)
気にすることに越したことはありませんが、C2レベルのセキュリティ基準も守れてないことになるので
今のOSではありえないでしょう。
例えば、rootで動いているdaemonが/etc/shadowの内容の書かれたメモリ内容をfree()したとして
一般ユーザが同じアドレスを確保した場合に/etc/shadowの中身が見えてると、いくらファイルで
パーミッションを600にしても意味がないということになるのでそれはセキュリティホールになるよね。
#今のOSで見つけたらそれは危険なセキュリティホールなので報告すべきだと思う
Re:不思議 (スコア:2, 興味深い)
まさにその例通りのセキュリティホールが発生した問題で、確かにその主張は正当だと思うんですが、
それはセキュアなOSの実装として望ましいという話であってコードの側で対策しなくてもよい(=OSの不手際)
か、というとそれは別の話ではないかと思います。
領域をクリアするにもコストがかかる訳で、このコストの回避を自前で対処することと引き替えに
行いたいかもしれない。その選択肢はプログラマの手にゆだねてもいいんじゃないかと。
実際、この問題の回避手段としては危険なメモリ領域はfree()する前にゼロクリアしておく、というの
でも十分可能ではないでしょうか。
OSレベルでしか対処できない、というのなら確かにOSのセキュリティホールだと思うんですけどね。
もちろんプログラマがポカミスをすることもあると思うのでユーザの選択としてメモリクリアを行って
くれるセキュアなOSを採用する、という手段はあると思うのですが、組み込み用OSや発展途上のOSなど
その優先順位や状況によってセキュアでないOSが世の中から無くなることはないように思いますし、
その選択もユーザが必要に応じて行うべきことだと思います。
ですので、この問題はアプリプログラマ側からみると環境依存の話何じゃないかと。
自分の書いたコードが利用される環境が完全にわかっているなら環境依存でもいいと思うのですが、
非環境依存のセキュアコーディング、という視点で見ると今回の問題は危険な領域は開放する前に
クリアしておくべき、ファイル出力するような領域もクリアしておくのが望ましいとかそのあたり
なのじゃないかなと。
#一プログラマとしては、何も気をつけなくていい楽ちん環境が当たり前になってくれるとうれしいのですけどね～。
#何か問題起きてもOSのせいにできちゃうような。OS開発者はたまったもんじゃないと思いますけど。
スルースキル：Lv2
Keep It Simple, Stupid!
Re:不思議 (スコア:1, 興味深い)
malloc(初期化しない)/calloc(初期化する）に相当するような初期化するfreeが
OSにあればそれを使うべきだし、無い以上は必要ならアプリケーション側で初期化
する必要がある。
OSレベルで実装されていようがいまいが（実装されていれば「それはいいＯＳです
ね」というだけのこと）、結局アプリケーション側で考慮しないといけないのは同じ。
Re: (スコア:0)
Re:不思議 (スコア:1)
オフトピだけど続けてみよう。
そのバグは昔踏んだことがあって、SunOS4のtarで固めたファイルを友人に送ったら「ホームディレクトリのディレクトリエントリが見える」って言われた。
# はずかしいファイル名が含まれていたかどうかは秘密だ。
Re:不思議 (スコア:2)
Re: (スコア:0)
gzip派生コードを使ったブラウザの方が深刻な気がする。
下手すりゃマルウェアのインストールにも使われそうですよ。
Re: (スコア:0)