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