zlibにセキュリティホール 22
ストーリー by kazekiri
影響はかなりでかいぞ 部門より
影響はかなりでかいぞ 部門より
take0m 曰く、 "ZDNNによると、Linuxの全てのバージョンに使われているzlib圧縮ライブラリに、セキュリティホールが見つかったそうです。 Linux以外で、BSDやSolarisなどでも利用されており、影響度は大きいが、脆弱性を利用できるかどうかは、OS次第とのことです。 こちらに詳細記事も掲載されています。"
とりあえず RedHatのErrata。zlibをstaticにしているプログラムは 影響を受けるということだが、かなりの数がありそうだ。 影響度はかなりでかいだろう。 [Update]、CERTの Vulnerability Note VU#368819では、OpenBSDが Not Vulnerableになっている。Vendor Satementには、 「OpenBSD is not vulnerable as OpenBSD's malloc implementation detects double freeing of memory. The zlib shipped with OpenBSD has been fixed in OpenBSD-current in January 2002.」さすがというか なんというか…。
zlibもそうだけど (スコア:3, 参考になる)
根本的な問題はglibcのmalloc()/free()に関するチェックが甘いってことで, FreeBSDやOpenBSDついでにWindows等ではその辺の処理が考えられているよ, という話 [slashdot.org]が本家の方に出ていましたが, 具体的にはどういう挙動をするのが良いのでしょうか?
FreeBSDでは/etc/malloc.confで挙動の設定ができるのですが(日本語マニュアルはまだ更新が追いついていないみたいです), currentでのdefaultの様にabortさせてしまうのが良いのでしょうか?
余談その1: 今月のUnixUserにこの2重free()を使ったクラックについての説明が有りましたが, 仕事が忙しくてまだ読んでいません.
余談その2: xlockmoreの中のatlantisスクリーンセーバ(OpenGLでクジラやサメが泳ぐやつ)が2重free()を終了時に起こしているみたいです. なもんでFreeBSD-currentではxlockコマンドをパラメータ無しで使うと, かならず途中で止まっちゃうんですよね.
phkmalloc(3)の場合 (スコア:2, 参考になる)
abort(3)(実際にはSIGABRTを自分に投げること)はそこそこ納得できる結果です。free memoryの管理構造が壊れかかっているので手早く片付けるにはsignalが最も便利です。ただ、vmやhardwareとの関連はないのでSIGSEGVやSIGBUSでは意味が合いません。
FreeBSDのphkmalloc(3)については、JSTの今朝方phkがデモを-currentと-stableに流してましたね。memoryの使用状況をfree listに書かない(実際にはmmap(2)で得たpageに書く)のがキモ。
Re:zlibもそうだけど (スコア:2, 参考になる)
最 近 の バージョンの Linux libc (5.4.23 以降) と GNU libc
(2.x) では、 malloc の動作を環境変数によって制御できるよう
な 実装がされている。 MALLOC_CHECK_ が設定されていると、特
殊な実装が用いられ、単純なエラーには耐えることができるよう
に なる (効率は悪くなる)。例えば free() を同じ引き数で二度
呼び出してしまう、 1 バイトだけ行きすぎてしま う (off-by-
one バグ) などがこれに当たる。しかしこれらのエラーの全てを
防ぐことができるわけではなく、その場合にはメモリリークが起
こっ て しまう。 MALLOC_CHECK_ が 0 にセットされていると、
ヒープの破壊を黙って無視する。 1 にセットされていると、 診
断 メッセージが標準エラー出力に表示される。 2 にセットされ
ていると、ただちに abort() が呼び出される。
Re:zlibもそうだけど (スコア:0)
ただ、こういうのがデフォルトになっているかどうかというのが、実は(いわゆる)GNU/Linuxと*BSDのいちばんの違いのような気がしています。デフォルトになっていれば、通常使用の支障にならない程度にはパフォーマンスが最適化され、ベンチマークでは若干不利な程度で堅牢性を享受できます。そういう意味で、glibcでMALLOC_CHECKをセットしたときのペナルティがどの程度なのか気になります。もし大してペナルティがないのなら、チェックするのをデフォルトにしてほしいなあ。
別の典型的な例としては
Re:zlibもそうだけど (スコア:0)
FreeBSDなら/sys/net/zlib.cね。
in-kernel memory alloocatorの場合 (スコア:2, 参考になる)
in-kernel zlibを使うのは、ppp(4)を用い、かつPPP_DEFLATEを追加した場合のみです。
allocatorにも対策があります。INVARIANTSを用いた場合はfree(9)でmultiple free(9)の検査を行ないます。また、Jeff RobersonのUniversal Memory Allocator(uma)では(まだ実装されていませんが)bucketの中で重複がないか検査する手でしょうね。
Mac OS Xの場合 (スコア:3, 参考になる)
昨日・・ (スコア:1)
・・遅れ馳せながら,openssl-0.9.6cをcompile して,openssh-3.1p1をcompileしてインストールしたばかりなのに,またcompileかい(泣
FreeBSDのホストだと,lddやstringsでver.3.1のsshdを覗いてみたところ,libz.so.2を見てるみたいだから,symbolic linkでOKか?
kero
Re:昨日・・ (スコア:0)
そんなソフトウェアはかなり多いような。
Re:昨日・・ (スコア:1)
Re:昨日・・ (スコア:0)
だとおもふ
Re:昨日・・ (スコア:1)
./configure --shared で作成されるのは,libz.so.1.1.4っバージョン番号がついた形なのね.libz.so.2って名前で作っちゃうのも何だから,symblic linkにするかなって思ってたのサ.
kero
ヘタレ管理者を導いてくれ (スコア:1)
ライブラリのアップデートと、あとは?
char *A;
モータースポーツ部 [slashdot.jp]
Re:ヘタレ管理者を導いてくれ (スコア:1)
つまり、zlib自体のアップデートと、それをstaticにリンクした
プログラムを何とかしないといけない(?)
rpmなどでインストールしたものは、対策済みのrpmを入れれば良いが、
ソースからmakeしたものはmakeし直す必要があるということでしょうか?
でもどれがzlibを使っているのやら。いちいちnddで調べる?
#そりゃ大変だ
Re:ヘタレ管理者を導いてくれ (スコア:1, 参考になる)
zlibをstaticにlinkしてるバイナリを検出するらしいperl script [gzip.org]
Re:ヘタレ管理者を導いてくれ (スコア:0)
これを自動化すると
ls / -lR | grep '^.*x ' |awk '{print $9}' > exfile && find / | fgrep -f exfile > exfilepath && file -f exfilepath | fgrep zlib
?
#いかん、これでは「おもしろおかしい」だ
Re:ヘタレ管理者を導いてくれ (スコア:0)
正直,手をつけられないよなあ.
ファイル一つ書き直すだけでレビューして,
文書化,変更してからテストだもんねえ.
全部リンクし直し,なんてなったら即死だな.
このバグは広義に致命傷じゃないかな.
とっくにfix済み (スコア:0)
しかし、OpenBSDでmozillaのbuildに二時間以上かかって
(システム再構築より時間かかったぞ)、あげくの果てに
Memory faultで起動してくれなかったのは悲しひ・・・。
Re:とっくにfix済み (スコア:0)
オリジナルへのフィードバックはしないことになっているのでしょうか?
Re:とっくにfix済み (スコア:0)
Teoはフィードバックしていると答えたらしい。
しかしfix済みにもかかわらずOpenBSDはpatchを公開。
現状にも満足しないみたい。
なんで (スコア:0)
もっと注目しようよ!
Re:なんで (スコア:1)
# mishimaは本田透先生を熱烈に応援しています