rsync 2.5.6 にバッファオーバーフローの脆弱性 22
ストーリー by yoosee
秘密の裏口 部門より
秘密の裏口 部門より
yosshy 曰く、 "rsync のトップページに、rsync 2.5.6 に発見されたバッファオーバーフローの脆弱性がアナウンスされている。このセキュリティホールを利用するとリモートからコードを実行できるとの事。バグフィックス版の 2.5.7 がリリースされている。"
この脆弱性の影響を受けるのは rsync を server として使っている場合のみ (this vulnerability only affects the use of rsync as a "rsync server".)。自分のサーバで rsyncd が動いているかどうかは、netstat 等で TCP port 873 番を listen しているかどうかで確かめられる。 Gentoo の乗っ取り も rsyncd が原因だったようだ。 また、この脆弱性でマシンに侵入され、先の linux kernel の脆弱性 で乗っ取りを受けるケースがあるので注意。さて、修正内容の rsync-2.5.6-2.5.7.diff.gz も見てみると... あらら、これ rsync だけの問題で終わるのかしらん?
何これ？ (スコア:2, 参考になる)
- malloc() → new(バイト数)
- malloc() → new_array(型, 配列数)
- Realloc() → realloc_array(ポインタ, 型, 配列数)
で全て書き直されていますね(C++ か何かの影響？)また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。GNU libc に問題があるのでしょうか？
Re:何これ？ (スコア:2, 興味深い)
これは と、_new_array、_realloc_arrayの の部分のことですか?。これは単なる桁あふれ対策に見えますが。 32ビットに固定しているのは楽をするためでしょうか。
# ちなみに1Gじゃなくて10Gですね。
……と思ったんですが、桁あふれ対策なら0x7FFFFFFFにしますね。(0xFFFFFFFFではないのは、size_tが符号つきの場合のことを考えてのこと)
ん～、やっぱり謎だ。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:何これ？ (スコア:2, すばらしい洞察)
batch_flist->malloced *= 2;
してメモリ再確保とかしているので、
というかんじでリリースしたのかなあと…
まあ安全側に振る分にはいいかもしれないんですが、どちらかというとこういうところで0x7FFFFFFFとか0x40000000とかいった数字をじかに書いてるのが心配だったり…
あと、0x40000000Byteは1GB(あるいは1GiB)だと思う。
-- Takehiro TOMINAGA // may the source be with you!
size_t(オフトピ気味) (スコア:1)
size_tが最低32ビット(longの最低保証されるされるサイズ)はあると仮定するのは問題ないと思ってましたが、今調べたら、符号なし整数としか定義されていないんですね。迂闊でした。
ということは、size_tのサイズが8ビット(shortの最低保証されるサイズ、16ビットより小さかったりしますが、charも整数に変わりはありませんし)な処理系があってもいいわけですね。最大255バイトしか確保できないmallocなんてヤですが。
ということは、size_tのサイズを調べて、それが表現できる最大の整数を調べるのが正しい道ですかね。
もっとも、rsyncを動かすような環境用の処理系なら、size_tのサイズが32ビット以上だと仮定しても問題ないとは思います。(←その発想が危険か……)
この辺、パッチを書いた方も同じような誤解をしているんでしょうかね。
-- 理解が不十分なことや推測をたれ流してしまったので、偉い人降臨ぷりーず
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:size_t(オフトピ気味) (スコア:2, 興味深い)
Re:何これ？ (スコア:0)
分からん (スコア:1)
> あらら、これ rsync だけの問題で終わるのかしらん?
って言われても、パッチのコードがさっぱり読めん俺には何がまずいのかが分からんのですけど。
rsyncだけの問題で終わらんのですか？理由は？何で書かないの？
rsync使ってるんだけど 873 番はlistenしてないみたい。
本当かな。ものすげえ自信無いんでサーバ毎落としてるんだけど。
# 個人サーバだから出来る芸当だな....
Re:分からん (スコア:2, すばらしい洞察)
ぱっとパッチを見た感じでは、ある構造体の配列を確保するときに、sizeof(ほげ) * n の計算でオーバーフローして、実際にはごく小さなメモリしか確保できてないことがある、っていう問題のようですね。
とくに目新しい種類のミスではないです。煽りたかっただけでしょう。
逆に言えば。 (スコア:1)
>とくに目新しい種類のミスではないです。
>煽りたかっただけでしょう。
逆にそういうミスが見つからずに、
今まで存在していたのが問題になる気がします。
「チェック体制は大丈夫だったのか？」とかね。
# 同じ過ちやミスは繰り返される物だと思うので、自戒を込めてID
## もちろん、無くす努力しろよ＞自分
Re:逆に言えば。 (スコア:0, すばらしい洞察)
>今まで存在していたのが問題になる気がします。
>「チェック体制は大丈夫だったのか？」とかね。
なにをおっしゃるやら。ご自身でsignatureに書いてるじゃないですか。「誰も信じちゃい
Re:逆に言えば。 (スコア:0)
「信用して使えるものがなにもない」という大問題を除けば、
他に問題は無いでしょうけど……
Re:分からん (スコア:0)
オーバーフロー自体はありきたりですが、ここで問題視されてるのは原因ではなく対処の方。
はい読み直し
Re:分からん (スコア:0)
> 本当かな。ものすげえ自信無いんでサーバ毎落としてるんだけど。
> # 個人サーバだから出来る芸当だな....
勉強しる。
もし RedHat や OS X でお気楽サーバなんだったらもっとストイックな
Re:分からん (スコア:0)
--daemonモードの話だったのね。使ってないです、そんなもん。
一応安心したので元に戻しました。
そういうわけでDebianの方もfix出てます。まだDebianセキュリティ情報 [debian.org]には出てないみたいだけども。
--
rsync (2.5.5-0.2) stable-security; urgency=high
* Non-maintainer release by the Security Team
* Fixes remote exploitable heap overflow vulnerability
* Applied patch from
Re:分からん (スコア:0)
という訳で詳しい人おねがい。
Re:分からん (スコア:2, すばらしい洞察)
Re:分からん (スコア:1)
本文に書くにしても煽りっぽい書き方をする必要はないですね…。失礼しました。
> Linux の malloc() 系の関数に問題があるという話ではまったくないです。
ふーむ、単に場当たり的(と言っても必要十分)な対処をしただけ、ってことですか。
なんで MALLOC_MAX を (1GB程度の) 定数値で入る必要があるのかが気になったのと、realloc で !ptr をわざわざ見てるのが何故かと思ったんですが、コードの他の部分でそういう危なさげな状況が起こり得るのでその回避なのかな。
Re:分からん (スコア:1, 参考になる)
reallocじゃなくてrealloc_arrayですね？
単にreallocとの互換性のためでしょ。
reallocはヌルポインタ渡されたらmallocと同じ動作をする事になっているので。
Re:分からん (スコア:1)
# 実はfreeも(笑)
そういえば (スコア:0)
#って、duplicityをホストしてるのって、クラックされたSavannahじゃん。(^^;;
rsyncといえば… (スコア:0)
->rsyncといえばgentoo
->gentooを攻撃
rsync使ってるのでac