glibcのgethostbyname系関数に脆弱性、「GHOST」と呼ばれる 20
ストーリー by hylom
これはでかい 部門より
これはでかい 部門より
あるAnonymous Coward 曰く、
クラウドセキュリティ企業Qualysの研究者が、GNU Cライブラリ(glibc)に深刻な脆弱性があることを発見した(JVNVU#99234709、CVE-2015-0235、ZDNet Japan)。
この脆弱性は「GHOST」と呼ばれており、これを利用することでリモートから任意のコードが実行される可能性があるという。
脆弱性が存在するのはglibc 2.2からglibc 2.17までで、piyologによるとglibcの__nss_hostname_digits_dots() にヒープバッファオーバーフローの脆弱性があり、この関数はgethostbyname()とgethostbyname2()で使われているという(Red Hat Bugzilla)。これら関数に細工されたURL文字列を与えることで、バッファオーバーフローを引き起こせる可能性があるようだ。
Qualysによれば、この問題は2013年5月21日にリリースされたglibc 2.17とglibc 2.18の間のバグフィックスで修正されているという。ところが、このバグフィックスはセキュリティ上の問題であるとは分類されていなかったため、多くのLinuxディストリビューションには適用されていないという。
影響を回避できそうなソフト (スコア:2)
QualysのSecurity Teamの投稿 [seclists.org]によれば、以下のソフトは影響を受けなさそうとのこと。
> apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
> nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,
> pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,
> vsftpd, xinetd.
なのでとりあえず自分は様子見。
Re: (スコア:0)
検証用 Redhat 5台
検証用 CentOS 15台
本番用 Redhat 3台
本番用 CentOS 50台前後
yumで適用して今のところ問題ありません。
glibcですが1月7日前後にも更新されていますので
yum-cronやyum-updatedでキャッシュしている場合
古いのを当てて満足しないように・・・大きなお世話か。
Re: (スコア:0)
ここにのっていないもので大物は、BINDくらいですかね?
未だに gethostbyname なんか使っているんじゃねぇよ (スコア:1)
Qualys のレポート [qualys.com]
- The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.
IPv6 に対応しようとしたら、必然的に getaddrinfo() を使うんで、意外に問題が起きないケースは少なく無さそう。
getaddrinfo() ならセーフかというと、厳密には getaddrinfo の中で gethostbyname2_r() を呼び出していて、でも、問題を引き起こすのには条件がキツイからセーフ、といった具合。ZDNet の記事 [zdnet.com]の煽り具合ほどでは無さそうな感じ。
そのむかしドレッパーたんがゆってました (スコア:0)
「長い文字列を黙って切り詰めることは許されない。文字列の長さを把握して領域を確保しろ。これが正しい文字列処理だ。」
できてないじゃん。
Re: (スコア:0)
彼は「お前に給料をもらった覚えはない」と言いながらgethostbyname()を修正したのかしら
解決策 (スコア:0)
Linuxを使わなければOk?
glibc は (スコア:1)
Linuxを使わなければOk?
SANSのダイアリー [sans.edu]によると
だそうだ。他に、静的に glibc がリンクされているプログラムも影響がある恐れ。あとは組み込み機器で glibc を採用していてネットワークを使うというかホスト名を扱うというか gethostbyname() を使うものも脆弱では。
Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers [openwall.com]によると
ねぇ。2000年11月にリリースされた版から脆弱、ですか。影響が広がりそう。
Re:解決策 (スコア:1)
東京都や大阪府、愛知県など [nhk.or.jp]「せやな」
Re: (スコア:0)
Theo「 そう、OpenBSDならね」
組み込み系は放置されそう (スコア:0)
組み込み系は放置されそうで怖いですな
Androidはlibcなのでセーフかな?
Re: (スコア:0)
組み込み系もそうだけれど、LinuxやBSD系をベースに使っているゲーム機も結構怪しい。
まあ、まともにセキュリティーメンテナンスされてもいないゲーム機のブラウザなんて、怖くて使えないけれどな。
さらに怖いのが、ネット対応のTVだけど、こんなもののブラウザなんて使っている人はいないか。
トラブルの源泉という想いしかない (スコア:0)
大抵はアプリ側が悪いのは分かってるんだけどさ。。
うちのglibcのバージョンいくつだっけ? (スコア:0)
脆弱性が存在するのはglibc 2.2からglibc 2.17までで
また勝ってしまった。敗北を知りたい。
Re: (スコア:0)
忘れてるだけだろ
Re: (スコア:0)
Re: (スコア:0)
うちのFedora 20(glibc-2.18-16.fc20.x86_64) もセーフだから、21もセーフだろうな。
Re: (スコア:0)
外向けのサーバー、既に5年はemerge --syncすらしてないけど生きてるますよ。
Re: (スコア:0)
相手にも選ぶ権利がありますよね