glibcに脆弱性 42
ストーリー by hylom
これは影響がデカい 部門より
これは影響がデカい 部門より
あるAnonymous Coward 曰く、
ほぼすべてのLinuxで使われているCライブラリ「glibc」に脆弱性が発見された（ITmedia）。
問題となっているのは、指定したホストのネットワーク的な情報を取得するためのgetaddrinfo関数で、スタックベースのバッファオーバーフローの脆弱性が誘発される可能性があるとのこと。2008年5月にリリースされたglibc 2.9以降のバージョンに存在するという。
また、Google Online Security Blogによると、2048バイトを超すサイズのUDPもしくはTCPレスポンスによって問題が発生するとのこと。迅速なglibcのアップデートおよびそれを利用するアプリケーションの再起動が推奨されているが、それができない場合に向けてファイアウォールなどでレスポンスサイズを制限することで一時的な対象も可能だという。
対処方法 (スコア:4, 参考になる)
殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。
CentOS 6.7 でやってみたところ、アップデートが来てました。
アップデート後は、glibc を使っているプロセスを全部再起動する必要があるので、可能であるならば OS ごと再起動（reboot）するのが確実です。
（glibcの脆弱性対策 より引用） [qiita.com]
どうしてもすぐにパッチあてや再起動ができないサーバの場合には、glibcの脆弱性対策（取り急ぎiptables/firewalldで叩き落とす！）for CVE-2015-7547 [qiita.com] を参考に、2048バイト以上のDNSレスポンスパケットをUDP/TCP共に廃棄するファイアウォールの設定を速やかに行っておきましょう。
Re: (スコア:0)
一時的な対処ですが，
名前解決に使うDNSサーバ上で，
2048バイト以上のレスポンスが返らなければ
とりあえずの対策になるんですかね？
Re: (スコア:0)
ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。
でも、正しい（けど大きい）レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。
正規のレスポンスで2048超える事ってよくあるものなんだろうか。
Re:対処方法 (スコア:3)
DNSの通信がそもそも安全性が確保されていないことので、その場合でも成り済まし攻撃は防げません。
EDNS0 (RFC 2671 の改良版の RFC 6891）の仕様では、
とあり、BINDなどの実装でもデフォルトで4096オクテットまで対応しているようです。
TXTレコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的になってきているので、2048オクテット以上のDNS応答を廃棄することで、正当な通信も一部阻害されてしまう可能性もあり得ますね。
なお、glibcの脆弱性対策（取り急ぎiptables/firewalldで叩き落とす！）for CVE-2015-7547 [qiita.com] のはてブコメントでは、
「長いDNSメッセージは、複数のIPパケットで送るだけなので、iptablesで落とすって無理じゃないの？？ ／ アプリ層のデータを複数のIPパケットで送るのはIPフラグメントとは全然別の処理だよ！」みたいに書かれていましたが、
DNS では、EDNS0 の仕様により、DNS のプロトコル自体でパケット分割行うことなく（NTPとかとは違う仕様です）、MTU (一般に1454～1500バイト）を超えるパケットの分割は下のレイヤーに任せているわけなので（TCPフォールバックの場合も同様）、
ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで（MTUが2048以上ということは普通無いので）、とりあえずの対策にはなるかと思います。
間違った対策は危険。スレッドストーリーも直した方が (スコア:0)
> ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで（MTUが2048以上ということは普通無いので）、とりあえずの対策にはなるかと思います。
ダメです。
間違った対策を勧めないようにしましょう。
TCPの場合、そもそも返答が１セグメントに収まってるという保証はありません。
1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。
ファイアウォールによる上記の制限では、防ぐことはできません。
実際、
http://qiita.com/kawaz/items/1b07429b28851f997dba#comme [qiita.com]
TCPフォールバック ＆ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした (スコア:2)
ご指摘ありがとうございます。
「（iptablesで）フラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄する」という対策は、UDPによるDNS通信（EDNS0 : RFC 6891 準拠、BIND9以降の初期設定で有効）には有効であっても、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした。お詫び申し上げます。
EDNS0（UDP）の場合は大きなデータの場合には、必ず IPフラグメンテーションが発生するので、iptables で制御可能です。
しかし、ご指摘いただいたとおり、TCPフォールバックの場合、TCPでは通信の効率化のために Maximum Segment Size（1452～1460バイトな場合が多い）ごとのセグメントに分割され、IPフラグメンテーションが発生しない2セグメントのTCPパケットとなることがあります。その場合、iptables で結合後のデータサイズをチェックしても複数セグメントの合算が行われない仕様となっているため（またフラグメンテーションされたIPパケットともみなされないため）、iptables では、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット による攻撃（2048バイト以上のDNS応答を受信してしまう）は防げませんでした。
iptables でこの攻撃を防ぐとしたら、TCPによるDNS通信を廃棄（TCPフォールバックの無効化）するしか無いようです。その場合であっても、TCPフォールバックは非効率（遅延に繋がる）であることからBIND9以降はEDNS0 がデフォルト有効なので問題が生じない場合も多いですが、EDNS0に対応していないサーバとの通信の場合には512 バイトを超える DNS メッセージを受信できなくなってしまうためTXTレコードの取得などの正常な通信にも影響が出てしまいます。弊害なく iptables のみで対策するのは不可能なようです。
CentOS (スコア:3)
今、アップデート確認したら125個も来てた。
こりゃ、再起動コースかな・・・
Debianだと (スコア:2)
sidにはパッチが当たったlibcが下りて来てますが、stretch(testing)はまだ。
http://metadata.ftp-master.debian.org/changelogs/main/g/glibc/glibc_2.... [debian.org]より：
多分、jessieやwheezyには降りてて、sqeeze-ltsはよくわからない(まだかも)。
Re:Debianだと (スコア:5, 参考になる)
jessie つまり stable も修正済みです
DSAから引用すると
> For the stable distribution (jessie), these problems have been fixed in version 2.19-18+deb8u3.
とのことです
なおglibcにはCVE-2015-7547だけでなく，さらに３つ脆弱性が発見されていて，今回のアップデートで修正されているとのことです
詳細は https://www.debian.org/security/2016/dsa-3481 [debian.org] をみてください
Re: (スコア:0)
発見者がFedoraの開発者であることもあってGentooなどのマイナーなディストリビューションを除いて主要なディストリビューションは既に修正済みのようですね。
なにいっとんのこいつ？ (スコア:1, 興味深い)
発見者がFedoraの開発者であることもあってGentooなどのマイナーなディストリビューションを除いて主要なディストリビューションは既に修正済みのようですね。
何を勘違いしてるのか知らんが、あらゆるディストリに先駆けて速攻で対策したのがGentooですから。
glibc-2.22用がこれ [gentoo.org]。 (2016-02-16 20:38:22)
glibc-2.21用がこれ [gentoo.org]。 (2016-02-16 19:01:28)
とっくの昔にrsync配布止めてるんで、.ebuildが書かれた瞬間にgithubからemerge --syncで一発で落ちてくるやね。
ええ。ビルドは各自勝手にするから、パッチ書くだけなんで速攻ですよ。
スラドのタレコミどころか、ITmediaの記事が出るより早いみたいなね。
そもそもこの速度に主要なディストリビューションとやらが着いてこれるわけねえじゃん。
むしろ何故Gentooがまだだと思ったのか理解できない・・・
つーか俺もそうだったけど、気が早い奴はportageで降ってくる前にepatch_userで勝手にパッチ当ててリビルドしてたんでねえの？
matsuu@厳冬あたりだったらepatch_userどころか、自分で.ebuildまで書いてmergeしてそうだし。
だいたいからして、他人が握ったライブラリ使うだけの輩と一緒くたにされたくはねえわな。
Re:なにいっとんのこいつ？ (スコア:2)
debian のリポジトリは 2016-01-31 に修正されています
https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=a398029... [debian.org]
そもそも CVE-2015 とあるようにこれは去年見つかったバグで，具体的には2015年の7月に報告されたものです
https://sourceware.org/bugzilla/show_bug.cgi?id=18665 [sourceware.org]
bugzillaにやり取りが記録されていますが，問題が指摘されてから修正されるまでに半年近く掛かっています．
つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明，修正作業を進めていた事になります
この全体の工程をみれば，アップデートの配布日が数日前後するのは些細なことですし
その数日の差で一喜一憂するのは末端の一部のユーザだけだと思います
Re: (スコア:0)
> bugzillaにやり取りが記録されていますが，問題が指摘されてから修正されるまでに半年近く掛かっています．
> つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明，修正作業を進めていた事になります
というよりも、実際に攻撃が成立する手法がなさそうな間は対処の優先順位が低かっただけでしょ
実際に手法が確立してこりゃやばいとなったから一気に修正しなきゃになっただけで
Re: (スコア:0)
そうそう。
みたいな順序じゃなかったっけ
毎度恒例の二重基準 (スコア:0)
bugzillaにやり取りが記録されていますが，問題が指摘されてから修正されるまでに半年近く掛かっています．
つまり glibcの開発者やディストリビューションのメンテナ達は半年前から原因究明，修正作業を進めていた事になります
邪悪なM$()が修正に半年もかけてたら
鬼の首でも取ったかのように大騒ぎするくせに
Re: (スコア:0)
え、普通に半年以上放置してから出てきているものもありますよね？
exploitが出てから影響範囲と期間のバランスなんじゃないの？ ユーザの手元にウイルスが届いているのにパッチがない状態だったら 普通に怒ると思いますが、今回はそうじゃないでしょ・・・
相変わらず、信者はどこの信者も気持ち悪いね
Re: (スコア:0)
お互いを信者と罵り合い、結局誰も何かに陶酔しているわけではないという…
Re: (スコア:0)
Gentooのパッケージシステムってそんな感じなのか、めっちゃ面白そう。
Archだと公式/準公式レポのビルド設定が気に食わない事が多くて、どうせmakepkgしちゃうんだよなぁ。
Re: (スコア:0)
/etc/portage/make.confにいろいろ書いておけば、あとは全部ソースからビルドしてくれるよ。これが標準。libreOfficeとかデカいのは、バイナリパッケージというのも可。
#たぶんArchでも同じようにできるのだろうけど、デフォルトがバイナリかソースからビルドかの違いなんかな？Archもちょっと使ってみたい。
Re: (スコア:0)
https://bugs.gentoo.org/show_bug.cgi?id=574880 [gentoo.org]
ここのcomment2
pre-notification channelsを持ってないのがマイナーな鳥
Re: (スコア:0)
Gentooって他のディストリビューションでも使えるコードを書いたりもせず、セキュリティの調査に参加したりもせず、ただ配布のみを行ってる印象でRedHatとは対照的。
「ライブラリを握るだけ」のディストリビューションなんですよね。
Re: (スコア:0)
Gentoo は成果を upstream に持ってこうとせずに
ディストリビューションの閉じた世界の中で
黒魔術を駆使しまくるイメージ。
Re: (スコア:0)
とりあえず、、、
「そうだ、そうだ」
＃遠山の金さんのおしらすの雑魚悪役風
Re: (スコア:0)
Linuxがだめなんじゃない。sraderがだめなんだよ。
Re: (スコア:0)
Microsoftを攻撃するだけじゃあきたらず、distro同士でも罵り合わないと気がすまないとか、すげえ連中だなあ。
Re: (スコア:0)
ってか、使用者は基本全方向に攻撃が正しい姿だと思うんだけどねｗ
所詮道具ごときに信者とか信じられんわ
今どきはOSが気に入らなくなれば、他のを使えばいいだけだろーに
・・・と言いつつ、仕事のPCをlubuntuにしてみたら、結構はまってちょっと辛い
Re: (スコア:0)
信者か攻撃対象の2者択一って、その考え方は完全に間違ってる。
だからダメなんだよ。
ああびっくりした (スコア:1)
去年の7月のやつじゃないか。
何を今更記事にしてるんだ?
Re: (スコア:0)
よくわかってないんだけど、去年の7月のやつとは何が変わったんだろう？
攻撃対象が増えた？ 前回は暫定対処だけで、根本解決のパッチがやっと出た？
「一時的な対象」は (スコア:0)
「一時的な対処」では？
Re: (スコア:0)
誰だい、このバグを仕込んだのは?
Re: (スコア:0)
バグじゃないよ、仕様だよ
Re: (スコア:0)
なら仕様が間違っていると上に突き返そう。
#それが出来たら苦労しないのでAC
GHOST対策 (スコア:0)
関連ストーリーに挙がっているgethostbyname()の脆弱性への対策では「getaddrinfo()使えば大丈夫！」なんてサジェストしてたみたいですが…こっちもダメだったんじゃねーか！
http://linux.srad.jp/comments.pl?sid=650658&cid=2751734 [linux.srad.jp]
ファイアウォールが (スコア:0)
glibcのgetaddrinfo関数使ってたらアウト？
今Linux、至る所にあるよね？ (スコア:0)
Androidやアプライアンスも中開けてみたらLinuxだったりしませんか？glibc使っていないといいけども…
Re: (スコア:0)
AndroidはカーネルはLinuxですが、libcはbionic libcという独自のものを使ってます。
アプライアンス系は、規模の小さいものだとuclibcとかnewlibなどにしている場合もありますが、普通にglibcをそのまま使っているのもありそうですね。
コイツ利用した奴で (スコア:0)
初のlinuxプロジェクトで、とあるソフトのバグ調査してて、ソース見たら一つの名前/アドレスが必ず来る前提で組まれてた奴見たとき絶句。
ゼロも二つ以上もダメというね。。
Winと違って～とかドヤ顔も印象深い。
もう10年位前だが、あそこの考え方からすると今もそのままだろうな。
Re: (スコア:0)
日本語でおk
Re: (スコア:0)
初のりなっくす計画で、柔らかの虫調査してて、西洋風醤油見たら一つの名前/住所が必ず来る前提で組まれてた奴見たとき絶句。
納得 (スコア:0)