NetBSDのlibcにリモートからのバッファオーバーランの危険性 (他UNIXも) 71
ストーリー by Oliver
あ~れ~ 部門より
あ~れ~ 部門より
who-am-i曰く、"Apache、OpenSSH と大物の入れ替え作業が続いていますが、今度は
NetBSD の libc に
リモートからバッファオーバーランの可能性 だそうです。
libc はもちろん、static link されているものの入れ替えも
必要ということだそうで、あちこちで悲鳴があがりそうな気が。
ちなみに 今月の Interface では NetBSD の安定性、移植性の良さを中心に組み込みシステムへのBSDの適用を特集している。これを機に国内ではいまいちマイナーなNetBSDも知名度アップ!?"
追記 (by O):どうやら*BSDだけでなく、BSD由来のリゾルバを使っているLinuxや他のUNIXも対象となるとか。UNIXじゃなくてもBSD由来のリゾルバを使っているOSは多そうなので、予想のつかない所にも飛び火しそうだ。
これ NetBSD だけじゃないでしょ? (スコア:2, 参考になる)
問題は、ココだろ。 (スコア:1, 参考になる)
Re:これ NetBSD だけじゃないでしょ? (スコア:0)
Re:これ NetBSD だけじゃないでしょ? (スコア:2, 参考になる)
まったく同じコードだったよ。よって、Linux も exploitable だと思われ。
Re:これ NetBSD だけじゃないでしょ? (スコア:1)
Re:これ NetBSD だけじゃないでしょ? (スコア:1)
但し、dns-network.cについては言及がありません。
Re:これ NetBSD だけじゃないでしょ? (スコア:1)
トコロがあるのでご注意を。
# 昨日 Vine-2.5 用 glibc パッケージの準備が完了。あとは
# static link モノの洗い出し。
Re:これ NetBSD だけじゃないでしょ? (スコア:1, 参考になる)
経験的に言って、statically linked binary は stripped binary でもあることが非常に多い。次のような一行スクリプトでさくっとstatically linked binaries を探索して無差別に入れ換えた方が良いかもしれない。
FreeBSDの場合、/usr/local/ にはあまり statically linked and stripped binaries は多くないようだ。ということはbuildworld/installworldの範囲で大体片付くってことだね。もっともbindはupdateを強いられるようだが。
Re:これ NetBSD だけじゃないでしょ? (スコア:1, 参考になる)
これをリンクしてるとアウトだと思われ。
libnsl 経由だと、コードがそっくり別物なので平気なようだが、
私の見落としがある可能性もあるので過信しないこと。
Windowsは? (スコア:0)
Re:Windowsは? (スコア:1)
Re:Windowsは? (スコア:0)
今回のバグは、DNS のクライアント側の問題で、
それが歴史的に BIND といっしょに提供されていた、ということです。
Re:Windowsは? (スコア:1)
#とはいえM$のことだから、DNSサーバーのない95系は全然別物って可能性はありますけど。
Re:Windowsは? (スコア:1)
MS-Windowsの名前解決は、lmhostsとかwinsとか色々絡んでるので...
# 実際どうかは知りません
## DNSのresolv関係はパクってそうな気はしますが
certには上がってないぞ (スコア:0)
JPCERTはもっと酷い (スコア:0)
やる気あるのか?
Re:JPCERTはもっと酷い (スコア:0)
金がないからできないというのなら、店たたんで欲しい。
できないくせに、できるかのような看板を立てるなっての。
Re:JPCERTはもっと酷い (スコア:0)
Re:JPCERTはもっと酷い (スコア:0)
Re:JPCERTはもっと酷い (スコア:0)
(1時間前のキャッシュを今リロードしたら表示された)
だから「なにか」って言われても・・・モゴモゴ。
酷い、ねぇ…… (スコア:2, すばらしい洞察)
あーだこーだ書いてる暇があったら、JPCERT/CC に情報提供のひとつもしてみたらどうなんだい?
SAが出てるのに不確実もくそもあるかってんだ (スコア:0)
不確実もくそもあるか。
securityfocusにものっていたのに名前に「緊急」が入る
CERTには情報が無いとはね。
知りたかったのはSUNとかの商用OSはどうかってとこなので
別に隠したいならそれでも良いんですがね。
追記 (スコア:2, 参考になる)
DNS のリゾルバ部分ということで、*BSD 以外にもあちこちで このコードが流用されている可能性もあり、結構大変な話かもしれません。
Re:やっぱりMacOS Xにも (スコア:1)
アップデートに時間食いそうだ。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:アップデートが出ました (スコア:1)
『Security Update July 2002リリース』 [srad.jp]
Re:追記 (スコア:2, 興味深い)
タレこんだ時点では、少なくとも私の知る限り NetBSDでしか話が 挙がっていませんでした。
また、状況を見てからたれ込んでいたのでは、鮮度が落ちる可能性が大きいです。こういうセンシティブな話だからこそ、とりあえず たれ込んで、それを叩き台に話/情報を広めていけばいいんではないでしょうか。
というだけでは芸がないので、FreeBSD [freebsd.org] と OpenBSD [openbsd.org] の一次ネタ元。
FreeBSD一次ネタ元URL (スコア:2, 参考になる)
chomy
Re:追記 (スコア:1, 興味深い)
編集者さんがまとめてくれるよ。
Re:追記 (スコア:0)
世の中の resolver の多くが BIND 由来というのは、ある意味常識。
まあ、タレコミ者にそのレベルを要求するのは酷かもしれんが、
そこで気づかんようなレベルの低い選者にはおおいに問題がある気がする。
見出しに出る、ということは影響が大きいんだからさ…
Re:追記 (スコア:0)
新たなコピペ用文章の誕生なのですか? (スコア:0)
世の中の「一般」の多くが独善というのは、ある意味常識。
まあ、#114701=#114902 [srad.jp]にそのレベルを要求するのは酷かもしれんが、
そこで気づかんようなレベルの低い
Re:新たなコピペ用文章の誕生なのですか? (スコア:0)
ネタにマジレスするようで寒いし、なんでもコピペにしたがる厨房に
こういうことを言っても無駄かもしれんが、
文脈とか状況をちゃんと見たほうがいいと思われ。
選者に高いレベルを要求するのと、一般ユーザに高いレベルを
要求するのをごっちゃにしちゃいかんですわ。
Re:新たなコピペ用文章の誕生なのですか? (スコア:0)
> 要求するのをごっちゃにしちゃいかんですわ。
ここは同意するけど
> こういう影響力の大きなサイトで責任ある立場の人間に、
/.Jってそんなに影響力、大きいのか?
本気でそう思ってる?
Re:センシティブな話 (スコア:1)
Don't ask me why!
悲鳴が上がる...ほどかな? (スコア:2, 興味深い)
通常, libcをスタティックリンクしてある実行ファイルって言うと/binや/sbinの下の, いわゆるシステムに含まれるコマンド群がほとんどですから, ほとんどルーチンワークの/usr/src下でのmake worldで対応できると思います. もちろん検証も必要ですが, それも従来の作業工数から大きく変わることは無いはずですし.
pkg-src/portsで導入する外部アプリケーションについては, ほぼ全てダイナミックリンクですから, 極例外的な物のみを押さえておけばOKだと思います. と言うか, 実際にスタティックリンクの物って(自分でリンクオプションを設定する以外に)何か有りますかね?
Re:悲鳴が上がる...ほどかな? (スコア:0)
けっこういろいろかくれてましたし、chrootさせてました。
また、クライアントすべてに影響するので悲鳴です。
どうするか、悩んでいます。
OpenBSDでは、 (スコア:1, 参考になる)
ココ [openbsd.org]をクリックすれば、貴方は幸せになれるかも。
6年近くもの間、初期インストールでのリモートセキュリティホールは一つだけでした。
何か、空しいな、、、、
買ってしまった... (スコア:0, オフトピック)
なかなか面白そうだったので買ってしまいました.
今月はBSD MagazineとFreeBSD Pressもあるのに予定外の出費...
Interfaceは千円しないのでまだよいのですが,学生には結構辛いです技術系雑誌の値段.
一食抜きです.
Re:買ってしまった... (スコア:0)
Re:買ってしまった... (スコア:0)
# それ以前に原稿まとめられるだけの能力があるか、だけど
Re:買ってしまった... (スコア:0)
PRELOADにて対策できないか?? (スコア:0)
そこで、ダイナミックリンクしているものに関しては、wrapper
ライブラリを作成し、LD_PRELOADを設定することで回避できないか、
と思ったのですが、このアイデア、どうでしょうか?
Re:PRELOADにて対策できないか?? (スコア:0)
カーネルだけの入れ替えに抵抗ありますか?
Re:PRELOADにて対策できないか?? (スコア:0)
会社で使っているのが問題なんです。
シミュレーションのデータ保存用にNFSでディスク共有していて、
いま、負荷が高めなんでちょっと止めにくいんです。
# 今週の日曜日あたりなら、いけそうですが、できれば避けたい。
それよりなにより、前人者からの経緯でTurboLinux7WSを使っているの
ですが、先日来のApacheでのゴタゴタを見るにつけ、メーカ提供の
RPMをブチ込むのは、今はやりたく
Re:PRELOADにて対策できないか?? (スコア:0)
どうなんだろうね。
個人的には、2.4.* 系のカーネルへの移行に抵抗感があるので、
未だに必要に応じて 2.2.20 を 3 分間 hacking して使ってます。
だって、2.4.18 にした途端、ディスクが暴走しちゃったんだもん。
djbdnsのdnscacheというのは (スコア:0)
これが外とリゾルバの間に入っていれば、DJB作なのでバッファオーバーフローには気をつけているのでしょうから、悪意あるサーバからの返答もサニタイズされそうな気がするのですが……
Re:djbdnsのdnscacheというのは (スコア:2, 参考になる)
ローカル DNS キャッシュサーバとして BIND 9 を使えば大丈夫、 BIND 8 はだめと書いてあります(BIND 8.3.3 を使ったらどうなんでしょう)。 djbdns については何も書いてありません。
鵜呑みにしてみる?
Re:djbdnsのdnscacheというのは (スコア:1)
鵜呑みにしてみる?
Re:djbdnsのdnscacheというのは (スコア:1)
しかし、このポリシーには不安を感じます。どんな入力を与えられてもまともな出力しかしないようにする(エラーを返したり入力を無視したりするのもまともな出力の一つとして)、というのがセキュアなプログラミングの基本だと思っているので……。
鵜呑みにしてみる?
機能していないのは、 (スコア:0)
やれやれ、貴方のような厨房管理者に限って、自分の欠陥を棚に
上げて他人に迷惑を掛けるのです。
CERTの皆様方は、日夜バグ潰しに専念しておられるのです。
ただ、貴方が当掲示板にアクセスして、尚且つセキュリティに関与する
内容に興味を示していた事を見ると、少なからず貴方のようなアホ
管理者でも、私はそれなりに関心いたしました。
ただ闇雲にCERTに依存し過ぎて、何らかの形でたまたま見落とした
モノ、又は誤った