zlib大丈夫か (151ﾚｽ)
zlib大丈夫か http://mevius.5ch.net/test/read.cgi/unix/1016204803/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
1: MSおまえもか？ [] 02/03/16 00:06 zlibやってくれたよな〜。 opensshバージョンアップしたとたんにリコンパイルかよ。 MSにまで広がってるのってなんでや？ あいつら密かにオープンソース売ってるんか？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/1
2: 名無しさん＠Ｅｍａｃｓ [] 02/03/16 00:07 2ｹﾞﾄｽﾞｻ http://mevius.5ch.net/test/read.cgi/unix/1016204803/2
3: 名無しさん＠Ｅｍａｃｓ [sage] 02/03/16 00:10 ﾂｲﾃﾞﾆ3ﾓｹﾞﾄｽﾞｻｰ http://mevius.5ch.net/test/read.cgi/unix/1016204803/3
4: 名無しさん@Vim%Chalice [sage] 02/03/16 00:14 4ｹﾞｯﾄｽﾞｻｰ http://mevius.5ch.net/test/read.cgi/unix/1016204803/4
5: にせむら りか [sage] 02/03/16 00:40 ５ http://mevius.5ch.net/test/read.cgi/unix/1016204803/5
6: zlib-1.1.3 [sage] 02/03/16 00:53 もうだめぽ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/6
7: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 01:24 コンパイル時の利便性取って各アプリで腹持ちしてるからこういう事に なるんだ。素直にshared libraryをrequireしときゃzlibだけの入れ 替えで済んだのによ。 と煽ってみたり。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/7
8: 電子のお金十箱 [sage] 02/03/16 01:28 2重freeが問題なので、一部のダサイ実装以外は気にしなくても平気らしい。 # それよりも、このネタでまたfj.comp.lang.cあたりでmalloc & freeが # 再燃しないか楽しみ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/8
9: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 01:38 ああ、それで塩兄さんの日記でそのネタやってたのか。 glibcは駄目みたいだね。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/9
10: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 02:22 zlib なんだかわかんないけどどりあえず ｱﾌﾟﾃﾞｰﾄ してみました。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/10
11: MSおまえもか？ [] 02/03/16 12:25 >7 確かにそうだね。可能なら全部sharedの方がいいかも。 LD_LIBRARY_PATH,LD_RUN_PATHの設定がめんどくせ〜けどね。 まさか/.profileで設定するわけにいかんし。さ〜こまった。 env LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" sshd ってか？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/11
12: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 12:25 >>7 kernel 回りもヤバい奴があったりするようだけどな。 ppp 関係とか。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/12
13: 名無しさん＠お腹いっぱい。 [] 02/03/16 17:55 スマン、何の話だかｻﾊﾟ-ﾘ分からんのだが、 良かったら誰か解説してくれぬか? http://mevius.5ch.net/test/read.cgi/unix/1016204803/13
14: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 18:23 >>13 >>10を見習えYO!(w http://mevius.5ch.net/test/read.cgi/unix/1016204803/14
15: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 18:49 >>11 漏れは djb 信者ぢゃないけど envdir http://mevius.5ch.net/test/read.cgi/unix/1016204803/15
16: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 18:50 ｳﾞｫｹの >>13 はすっこんでろ http://mevius.5ch.net/test/read.cgi/unix/1016204803/16
17: 名無しさん＠お腹いっぱい。 [] 02/03/16 19:39 >> 13 厨房なので、間違えているかもしれんが zlibとは、圧縮用ライブラリである。このライブラリに セキュリティホールが発見された。 最近のunixは、共有ライブラリを使うもの(多数のプログラム で同じライブラリを共有する)だが 一部のプログラムは、zlibをstaticでリンクしており、この 弊害の方が今回の騒動で、顕著になった。 rsync,ssh,kernelなどでzlibをつかっている ++++ LD_LIBRARY_PATHの話は、どこからライブラリをロードするか を決定する話。 glibcの話は、チェックしていないのパス http://mevius.5ch.net/test/read.cgi/unix/1016204803/17
18: 13 [sage] 02/03/16 21:27 >>17 ご説明ありがとうございます。 なるほど、staticリンクの問題でしたか。 そう思って読み返してみると意味が分かりました。 厨房にお付き合いの程感謝申し上げまする m(_ _)m http://mevius.5ch.net/test/read.cgi/unix/1016204803/18
19: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 21:30 >>17 発見されたのはセキュリティホールではなくバグ。 このバグがセキュリティーホールにつながるかどうかは、 他のライブラリに依存する。これが glibc の話に関わってくる。 で、glibc を使ってるシステムはちょっとやばいかも、という話。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/19
20: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 21:40 openbsd神話崩壊ですか？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/20
21: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 21:55 >>20 どういうこと？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/21
22: 名無しさん＠お腹いっぱい。 [sage] 02/03/16 22:27 >>20 「デフォルトの設定で」はpppもipcompもsshも使ってないので 問題ないと思う。(w http://mevius.5ch.net/test/read.cgi/unix/1016204803/22
23: login:Penguin [] 02/03/16 22:30 >>21 > どういうこと？ しらんけど、 http://www.cert.org/advisories/CA-2002-07.html すら読んでないんだろ。ほっとけ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/23
24: 親切な人 [親切な人] 02/03/16 22:35 ヤフーオークションで、凄い人気商品、発見！！！ 「高性能ビデオスタビライザー」↓ http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA ヤフーオークション内では、現在、このオークション の話題で、持ちきりです。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/24
25: MSおまえもか？ [] 02/03/16 23:00 libpngとかも関係してるし。 ありえんと思うけどIE開いたとたんにワームに感染な〜んて！ あったら怖いな。 けど、sunsiteとかからパッケージダウンロードしてる最近の サーバモンキーとかいう奇特なお方は知らぬ間にセキュリティー ホール作ってるてことだよなぁ。 実はそういうお方が一番怖いと思うね。俺わ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/25
26: 名無しさん＠お腹いっぱい。 [] 02/03/17 00:27 私のところのマシンのOpenSSHはどれも、libzをdynamic linkしてるけど? >>1 http://mevius.5ch.net/test/read.cgi/unix/1016204803/26
27: 外出しとおもうが [] 02/03/17 12:30 MSはコードをパクっているらしいな。 http://japan.cnet.com/Enterprise/News/2002/Item/020315-5.html?me http://mevius.5ch.net/test/read.cgi/unix/1016204803/27
28: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 12:43 >>25 ネタ? ソースからコンパイルしても安全ってわけじゃないんだけど http://mevius.5ch.net/test/read.cgi/unix/1016204803/28
29: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 13:01 あのさ、漏れ ssh-1.2.27 （クライアント側のみ）使ってんだけどさ。 これ危ないの？ この話に限らないんだけど、 セキュリティーの話ってはっきり言ってもううんざりなんだよ。 そんなの細かいこと気にしてたら気にしなきゃならないことだらけで やってられん。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/29
30: マカー [sage] 02/03/17 13:31 あの〜OS Xもヤヴァいんでしょうか http://mevius.5ch.net/test/read.cgi/unix/1016204803/30
31: MSおまえもか？ [] 02/03/17 13:41 >>25 少なくとも、何をリンクして何をしているかの見分けはつくっしょ。 やばそうなら、入れなきゃいいし、ソースいぢれるし。 C系列が分かんなきゃ話にならんけど。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/31
32: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 13:50 >>28 >>25は全ソースをauditしている スーパーハッカーです。たぶん。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/32
33: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 13:53 >>9 MALLOC_CHECKに敢えて触れていないワナ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/33
34: 名無しさん＠Ｅｍａｃｓ [sage] 02/03/17 14:02 http://www.gzip.org/zlib/apps.html DirectX にも zlib が。 うかうかとエロゲもやってられません。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/34
35: 名無しさん＠お腹いっぱい。 [] 02/03/17 14:03 >>34 心配するなよ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/35
36: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 14:06 FreeBSDとかは２重解放はデフォルトでチェックするけど、 char *buf=malloc(100); free(buf); buf[10] = 10; なんてコードには約立たずなのはどこもいっしょ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/36
37: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 14:22 >>36 ん？そういうコードが zlib に含まれてるの？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/37
38: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 14:39 っていうか大騒ぎしすぎな気がする http://mevius.5ch.net/test/read.cgi/unix/1016204803/38
39: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 14:46 もちろん一般論だYO。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/39
40: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 14:56 >>39 あんまりむやみに話膨らますなＹＯ！ (特に malloc() & free() 話は) http://mevius.5ch.net/test/read.cgi/unix/1016204803/40
41: 名無しさん＠お腹いっぱい。 [5age] 02/03/17 15:38 だれか>>26に答えてくれ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/41
42: login:Penguin [sage] 02/03/17 15:57 >>41 反語は強調やほのめかしに使うもんで、答える対象じゃないだろ? ↑この文に答えるなよ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/42
43: 名無しさん＠お腹いっぱい。 [] 02/03/17 16:10 >>1 のいみがよくわからんってことでしょう http://mevius.5ch.net/test/read.cgi/unix/1016204803/43
44: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 16:17 >>42は反語の意味がわかっているのだろうか？（いやわかっていない） http://mevius.5ch.net/test/read.cgi/unix/1016204803/44
45: 名無しさん＠お腹いっぱい。 [] 02/03/17 16:20 zlib になにがあったの？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/45
46: 名無しさん＠Ｅｍａｃｓ [] 02/03/17 16:21 つーか、GPL適用しとけば、MSがソースコカーイとかあったかもしれないのに。 ザンネソ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/46
47: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 16:28 もしGPLだったら、使わずにスクラッチから実装するだけでしょ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/47
48: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 16:33 >>47 で、実装バグにより(以下略) http://mevius.5ch.net/test/read.cgi/unix/1016204803/48
49: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 16:51 >>48 しかも独自拡張部分で(以下略) http://mevius.5ch.net/test/read.cgi/unix/1016204803/49
50: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 17:35 >>48 zlib相当を作るときはまともなプログラマ使うだろ。 MSのプログラマはスーパーハカーから超ヘタレまで格差ありすぎ(w http://mevius.5ch.net/test/read.cgi/unix/1016204803/50
51: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 18:17 >>50 では今回のzlib問題はMSについては問題ないとゆーことですね。 スーパーハカーがまともなzlib互換libを作ったんでしょ？(w http://mevius.5ch.net/test/read.cgi/unix/1016204803/51
52: 名無しさん＠お腹いっぱい。 [sage] 02/03/17 18:23 >>51 はいはいそうですよ。読解け。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/52
53: 名無しさん＠お腹いっぱい。 [] 02/03/19 01:05 >> 29 それなりに大雑把にいきたいなら apt教 に入信するとよろし、開発側の体制がしっかり しているなら、他人まかせにできるな http://mevius.5ch.net/test/read.cgi/unix/1016204803/53
54: 名無しさん＠お腹いっぱい。 [] 02/03/19 04:54 kernel内部の libzとかは大丈夫なんでしょうか? >>お前ら free(3) は大丈夫でも free(9) で商店とかありませんか? いや、sourceをちっとも見ないでいってるんですけど。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/54
55: 名無しさん＠お腹いっぱい。 [] 02/03/19 10:28 >>54 今回の問題の根本はdouble freeという現象であって、意図的に加工された .gzファイルを展開しようとしたときに意図しないコードが実行する可能性 がある、というもの。 従って、カーネルのように信頼できるものを展開する際にはセキュリティ上 の問題になることはないはず。例外として発信元不明な謎のカーネル（また はモジュール）をコンパイルしてインストールすればセキュリティホールを 突くこともできるが、そんな面倒なことをやるくらいならそのカーネルか モジュールのソースそのものに穴を用意すればいいだけのことだし、何より も信頼できないソースを利用すること自身が既に問題。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/55
56: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 11:14 >54 通信のデータとかをカーネル内部で圧縮していたら？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/56
57: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 11:39 >>56 Linux だと drivers/net/zlib.c があって ppp がこれつかってるな。 2.4.19-pre* のどっかで修正されたようだ。 悪意のある ppp server/client がいるとヤバイか? あと fliesystem 方面にも入ってる。信頼できない fs image を loopback で mount したりするとヤバイかもね。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/57
58: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 18:13 FreeBSD と OpenBSD はパッチでたね。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/58
59: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 19:36 XFree86-4.2.0も出てまっせ。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/59
60: kcrt [nh] 02/03/19 21:22 MSはコード公開しる！ ・・・あ、汚いWind*wsのコードとか見せられると使う気なくすなぁ http://mevius.5ch.net/test/read.cgi/unix/1016204803/60
61: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 21:44 >>60 ソースが汚ないってよく言うけど、具体的にはどんなの？ ≒読み難い(eg. qmail)ってことでいいんでしょうか。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/61
62: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 21:48 >>60はつねにきれいなコードを書く神あるいはしろうと。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/62
63: kcrt=60 [nh] 02/03/19 21:53 汚い＝ＭＦＣのコード。なんか、あれ構造おかしくない？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/63
64: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 22:25 MFC は別になんとも思わなかったが... 俺が鈍感なだけ？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/64
65: 名無しさん＠お腹いっぱい。 [sage] 02/03/19 23:17 MFCは問題ないんでない？ http://mevius.5ch.net/test/read.cgi/unix/1016204803/65
66: login:Penguin [] 02/03/20 00:02 MFCのソースコードは読んだことないが、 クラス階層がしょぼい http://mevius.5ch.net/test/read.cgi/unix/1016204803/66
67: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 00:02 >>61 breakflag = 0; for( なんかループ ){ for( なんかループ ){ if(なんか条件){ breakflag = 1; goto NASTY; } } } NASTY: if(breakflag){ なんかさいあくなしょり } 見たいなのをいふんだＹＯ！ http://mevius.5ch.net/test/read.cgi/unix/1016204803/67
68: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 00:11 >>67 gotoとかMSが使わせるとは思えんが。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/68
69: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 09:39 >>60 MS=ソース汚い, ってのは短絡的じゃない? あー、外部から分かる動作でソースコードの汚さが 推測できる、のかもしれないが。 # 大学にNTのソースライセンス提供したとかいう話もあったな。慶応だったか。 # ここに読んだことがあるやついるかな。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/69
70: login:Penguin [] 02/03/20 09:52 CMUとかMITとかも持ってるよ。 今やNTはMicrosoftのコードだけで動いているわけではないし。メーカも書いてる。 SEGAに来たCEのソースは厨房レベルだったって。 コーディングスタイルが汚いとかどうかという以前に、 アルゴリズム、OSの基礎知識がない奴がコーディングにかり出された感じらしい。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/70
71: 名無しさん＠お腹いっぱい。 [] 02/03/20 11:51 中でzlibつかって圧縮かけてやってるロジックがあったとしても、 展開対象のデータに悪意のあるデータが入っている場合のみ穴になる、と。 第三者から渡されたtar玉になんか仕組んであったとしても、 それはWindowsでいうところの "exeファイルがついてあるときは、相手にそのファイルをどう扱ったらいいか聞いて対処しなさい" 問題と同じであるから、利用者問題だわな。 プロトコルスタック内部で圧縮展開なんかやってる部分に関しては、 そういうデータと同じデータの並びになるようなデータ列を処理したときのみ起こり得る。 うまくそういうIPパケットを流すことができるのであれば、それはそれで穴にはなるだろうが、 せいぜい経路上の次のノードに対してそういうのを流すことができる程度か？ ヘッダー内容とそういう並びのデータ列とがうまくマッチするケースがあるかどうかで 可能かどうかわかるんじゃろーけんど。（まあありえんか・・・） http://mevius.5ch.net/test/read.cgi/unix/1016204803/71
72: 名無しさん＠お腹いっぱい。 [] 02/03/20 12:23 >>71 > 利用者問題だわな。 んなアホな。 そんなことを言ったら、圧縮するプロトコル (HTTP とか PPP とか) は 成り立たないじゃん。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/72
73: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 12:55 >>71 はイメージだけで書いてるに1票。 http://mevius.5ch.net/test/read.cgi/unix/1016204803/73
74: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 13:20 漏れ、自己解凍のLHAやZIP形式の*.exeファイルもらった時も、 UNIX上でlhaやunizpで直接解凍して、 決してWin上で実行しないようにしてる。 でもそれでも安全ではなくなるのか… http://mevius.5ch.net/test/read.cgi/unix/1016204803/74
75: アフォ? [sage] 02/03/20 15:51 >>74 > でもそれでも安全ではなくなるのか… つーか、「漏れ」の話なら、安全にすればいいじゃん。まだやってないの? http://mevius.5ch.net/test/read.cgi/unix/1016204803/75
76: 名無しさん＠お腹いっぱい。 [sage] 02/03/20 23:37 >>74 ふつうに win 上で unzip とか lha で 解凍すればいいのでは？？？？ なぜわざわざ UNIX 上でやるのか、 そして zip や lha はスレ違いなこと、 なにもかもが わけわからん(w http://mevius.5ch.net/test/read.cgi/unix/1016204803/76
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 75 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.016s