1read 100read
2011年10月1期UNIXzlib大丈夫か TOP カテ一覧 スレ一覧 削除依頼 ▼
・　次のスレ
4月からシステム管理することになったんだけど
替え歌スレ@UNIX板
Autoconf,Automakeについて
懺悔の部屋 (in UNIX板)


zlib大丈夫か


1 ：02/03/16 〜 最終レス ：10/11/10
zlibやってくれたよな〜。
opensshバージョンアップしたとたんにリコンパイルかよ。
MSにまで広がってるのってなんでや？
あいつら密かにオープンソース売ってるんか？

2 ：
2ｹﾞﾄｽﾞｻ

3 ：
ﾂｲﾃﾞﾆ3ﾓｹﾞﾄｽﾞｻｰ

4 ：
4ｹﾞｯﾄｽﾞｻｰ

5 ：
５

6 ：
もうだめぽ。

7 ：
コンパイル時の利便性取って各アプリで腹持ちしてるからこういう事に
なるんだ。素直にshared libraryをrequireしときゃzlibだけの入れ
替えで済んだのによ。
と煽ってみたり。

8 ：
2重freeが問題なので、一部のダサイ実装以外は気にしなくても平気らしい。
# それよりも、このネタでまたfj.comp.lang.cあたりでmalloc & freeが
# 再燃しないか楽しみ。

9 ：
ああ、それで塩兄さんの日記でそのネタやってたのか。
glibcは駄目みたいだね。

10 ：
zlib なんだかわかんないけどどりあえず ｱﾌﾟﾃﾞｰﾄ してみました。

11 ：
>7 確かにそうだね。可能なら全部sharedの方がいいかも。
LD_LIBRARY_PATH,LD_RUN_PATHの設定がめんどくせ〜けどね。
まさか/.profileで設定するわけにいかんし。さ〜こまった。
env LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" sshd
ってか？

12 ：
>>7
kernel 回りもヤバい奴があったりするようだけどな。
ppp 関係とか。

13 ：
スマン、何の話だかｻﾊﾟ-ﾘ分からんのだが、
良かったら誰か解説してくれぬか?

14 ：
>>13
>>10を見習えYO!(w

15 ：
>>11
漏れは djb 信者ぢゃないけど envdir

16 ：
ｳﾞｫｹの >>13 はすっこんでろ

17 ：
>> 13
厨房なので、間違えているかもしれんが
zlibとは、圧縮用ライブラリである。このライブラリに
セキュリティホールが発見された。
最近のunixは、共有ライブラリを使うもの(多数のプログラム
で同じライブラリを共有する)だが
一部のプログラムは、zlibをstaticでリンクしており、この
弊害の方が今回の騒動で、顕著になった。
rsync,ssh,kernelなどでzlibをつかっている
++++
LD_LIBRARY_PATHの話は、どこからライブラリをロードするか
を決定する話。
glibcの話は、チェックしていないのパス

18 ：
>>17
ご説明ありがとうございます。
なるほど、staticリンクの問題でしたか。
そう思って読み返してみると意味が分かりました。
厨房にお付き合いの程感謝申し上げまする m(_ _)m

19 ：
>>17
発見されたのはセキュリティホールではなくバグ。
このバグがセキュリティーホールにつながるかどうかは、
他のライブラリに依存する。これが glibc の話に関わってくる。
で、glibc を使ってるシステムはちょっとやばいかも、という話。

20 ：
openbsd神話崩壊ですか？

21 ：
>>20
どういうこと？

22 ：
>>20
「デフォルトの設定で」はpppもipcompもsshも使ってないので
問題ないと思う。(w

23 ：
>>21
> どういうこと？
しらんけど、
http://www.cert.org/advisories/CA-2002-07.html
すら読んでないんだろ。ほっとけ。

24 ：

ヤフーオークションで、凄い人気商品、発見！！！
「高性能ビデオスタビライザー」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA
ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

25 ：
libpngとかも関係してるし。
ありえんと思うけどIE開いたとたんにワームに感染な〜んて！
あったら怖いな。
けど、sunsiteとかからパッケージダウンロードしてる最近の
サーバモンキーとかいう奇特なお方は知らぬ間にセキュリティー
ホール作ってるてことだよなぁ。
実はそういうお方が一番怖いと思うね。俺わ。

26 ：
私のところのマシンのOpenSSHはどれも、libzをdynamic linkしてるけど? >>1

27 ：
MSはコードをパクっているらしいな。
http://japan.cnet.com/Enterprise/News/2002/Item/020315-5.html?me

28 ：
>>25 ネタ?
ソースからコンパイルしても安全ってわけじゃないんだけど

29 ：
あのさ、漏れ ssh-1.2.27 （クライアント側のみ）使ってんだけどさ。
これ危ないの？
この話に限らないんだけど、
セキュリティーの話ってはっきり言ってもううんざりなんだよ。
そんなの細かいこと気にしてたら気にしなきゃならないことだらけで
やってられん。

30 ：
あの〜OS Xもヤヴァいんでしょうか

31 ：
>>25
少なくとも、何をリンクして何をしているかの見分けはつくっしょ。
やばそうなら、入れなきゃいいし、ソースいぢれるし。
C系列が分かんなきゃ話にならんけど。

32 ：
>>28
>>25は全ソースをauditしている
スーパーハッカーです。たぶん。

33 ：
>>9
MALLOC_CHECKに敢えて触れていないワナ。

34 ：
http://www.gzip.org/zlib/apps.html
DirectX にも zlib が。
うかうかとエロゲもやってられません。

35 ：
>>34
心配するなよ。

36 ：
FreeBSDとかは２重解放はデフォルトでチェックするけど、
char *buf=malloc(100);
free(buf);
buf[10] = 10;
なんてコードには約立たずなのはどこもいっしょ。

37 ：
>>36
ん？そういうコードが zlib に含まれてるの？

38 ：
っていうか大騒ぎしすぎな気がする

39 ：
もちろん一般論だYO。

40 ：
>>39
あんまりむやみに話膨らますなＹＯ！
(特に malloc() & free() 話は)

41 ：
だれか>>26に答えてくれ。

42 ：
>>41
反語は強調やほのめかしに使うもんで、答える対象じゃないだろ?
↑この文に答えるなよ。

43 ：
>>1 のいみがよくわからんってことでしょう

44 ：
>>42は反語の意味がわかっているのだろうか？（いやわかっていない）

45 ：
zlib になにがあったの？

46 ：
つーか、GPL適用しとけば、MSがソースコカーイとかあったかもしれないのに。
ザンネソ。

47 ：
もしGPLだったら、使わずにスクラッチから実装するだけでしょ。

48 ：
>>47
で、実装バグにより(以下略)

49 ：
>>48
しかも独自拡張部分で(以下略)

50 ：
>>48
zlib相当を作るときはまともなプログラマ使うだろ。
MSのプログラマはスーパーハカーから超ヘタレまで格差ありすぎ(w

51 ：
>>50
では今回のzlib問題はMSについては問題ないとゆーことですね。
スーパーハカーがまともなzlib互換libを作ったんでしょ？(w

52 ：
>>51
はいはいそうですよ。読解け。

53 ：
>> 29
それなりに大雑把にいきたいなら apt教
に入信するとよろし、開発側の体制がしっかり
しているなら、他人まかせにできるな

54 ：
kernel内部の libzとかは大丈夫なんでしょうか? >>お前ら
free(3) は大丈夫でも free(9) で商店とかありませんか?
いや、sourceをちっとも見ないでいってるんですけど。

55 ：
>>54
今回の問題の根本はdouble freeという現象であって、意図的に加工された
.gzファイルを展開しようとしたときに意図しないコードが実行する可能性
がある、というもの。
従って、カーネルのように信頼できるものを展開する際にはセキュリティ上
の問題になることはないはず。例外として発信元不明な謎のカーネル（また
はモジュール）をコンパイルしてインストールすればセキュリティホールを
突くこともできるが、そんな面倒なことをやるくらいならそのカーネルか
モジュールのソースそのものに穴を用意すればいいだけのことだし、何より
も信頼できないソースを利用すること自身が既に問題。

56 ：
>54
通信のデータとかをカーネル内部で圧縮していたら？

57 ：
>>56
Linux だと drivers/net/zlib.c があって ppp がこれつかってるな。
2.4.19-pre* のどっかで修正されたようだ。
悪意のある ppp server/client がいるとヤバイか?
あと fliesystem 方面にも入ってる。信頼できない fs image を
loopback で mount したりするとヤバイかもね。

58 ：
FreeBSD と OpenBSD はパッチでたね。

59 ：
XFree86-4.2.0も出てまっせ。

60 ：
MSはコード公開しる！
・・・あ、汚いWind*wsのコードとか見せられると使う気なくすなぁ

61 ：
>>60
ソースが汚ないってよく言うけど、具体的にはどんなの？
≒読み難い(eg. qmail)ってことでいいんでしょうか。

62 ：
>>60はつねにきれいなコードを書く神あるいはしろうと。

63 ：
汚い＝ＭＦＣのコード。なんか、あれ構造おかしくない？

64 ：
MFC は別になんとも思わなかったが...
俺が鈍感なだけ？

65 ：
MFCは問題ないんでない？

66 ：
MFCのソースコードは読んだことないが、
クラス階層がしょぼい

67 ：
>>61
breakflag = 0;
for( なんかループ　){
for( なんかループ　){
if(なんか条件){
breakflag = 1;
goto NASTY;
}
}
}
NASTY:
if(breakflag){
なんかさいあくなしょり
}
見たいなのをいふんだＹＯ！

68 ：
>>67
gotoとかMSが使わせるとは思えんが。

69 ：
>>60
MS=ソース汚い, ってのは短絡的じゃない?
あー、外部から分かる動作でソースコードの汚さが
推測できる、のかもしれないが。
# 大学にNTのソースライセンス提供したとかいう話もあったな。慶応だったか。
# ここに読んだことがあるやついるかな。

70 ：
CMUとかMITとかも持ってるよ。
今やNTはMicrosoftのコードだけで動いているわけではないし。メーカも書いてる。
SEGAに来たCEのソースは厨房レベルだったって。
コーディングスタイルが汚いとかどうかという以前に、
アルゴリズム、OSの基礎知識がない奴がコーディングにかり出された感じらしい。

71 ：
中でzlibつかって圧縮かけてやってるロジックがあったとしても、
展開対象のデータに悪意のあるデータが入っている場合のみ穴になる、と。
第三者から渡されたtar玉になんか仕組んであったとしても、
それはWindowsでいうところの
"exeファイルがついてあるときは、相手にそのファイルをどう扱ったらいいか聞いて対処しなさい"
問題と同じであるから、利用者問題だわな。
プロトコルスタック内部で圧縮展開なんかやってる部分に関しては、
そういうデータと同じデータの並びになるようなデータ列を処理したときのみ起こり得る。
うまくそういうIPパケットを流すことができるのであれば、それはそれで穴にはなるだろうが、
せいぜい経路上の次のノードに対してそういうのを流すことができる程度か？
ヘッダー内容とそういう並びのデータ列とがうまくマッチするケースがあるかどうかで
可能かどうかわかるんじゃろーけんど。（まあありえんか・・・）

72 ：
>>71
> 利用者問題だわな。
んなアホな。
そんなことを言ったら、圧縮するプロトコル (HTTP とか PPP とか) は
成り立たないじゃん。

73 ：
>>71 はイメージだけで書いてるに1票。

74 ：
漏れ、自己解凍のLHAやZIP形式の*.exeファイルもらった時も、
UNIX上でlhaやunizpで直接解凍して、
決してWin上で実行しないようにしてる。
でもそれでも安全ではなくなるのか…

75 ：
>>74
> でもそれでも安全ではなくなるのか…
つーか、「漏れ」の話なら、安全にすればいいじゃん。まだやってないの?

76 ：
>>74
ふつうに win 上で unzip とか lha で
解凍すればいいのでは？？？？
なぜわざわざ UNIX 上でやるのか、
そして zip や lha はスレ違いなこと、
なにもかもが わけわからん(w

77 ：
>>72-73
プロトコルスタック中でのzlib利用時に懸念されることがらも併記してしてんのに
イメクラ状態レスなんかいな。
つか、自明の理しかかいとらんのだが・・・いったいどーかけというのやら。

78 ：
>>77
> つか、自明の理しかかいとらんのだが・・・いったいどーかけというのやら。
明快に簡潔に書く。

79 ：
じゃ　めいかいにかく
・圧縮されたファイルをもらいました　どうしよう？（どうしよう？）
　→そもそも信頼できない相手から来た郵便をあけるなんていうのは
　　　ユナボナーの犠牲者になりたい団の一員としか思えませんね　自業自得でしょう
・通信のなかで圧縮展開してる部分がありますよね？
　ヘンなデータでつつかれてクラックされたりしたらどうしよう？（どうしよう？）
　→圧縮はヘッダーも圧縮している場合が多いです。
　　都合よくクラックできるコードを埋めこめるようなパケットやセグメントをうまくつくれる確率は
　　低いでしょう　万一クラックされたら、逆に幸運の持ち主なのかも・・・

80 ：
そんな幸運うれしくないYO!

81 ：
>>74 解凍ができるのはlhaだけ…

82 ：
つーか自己解凍式書庫は今回のzlib云々とは無関係の所でもリスクはあるんだが
(自己展開部分になんか仕込まれてるとか)

83 ：
>>81
zipもできるよ。

84 ：
>>83 (ﾟДﾟ)ﾊｧ?

85 ：
>>83
http://www3.justnet.ne.jp/~s_kishimoto/fj/misc/fj-words.htm#KAITO_

86 ：
>>79
RFC も コードも見てないでしょ？
特に
> →圧縮はヘッダーも圧縮している場合が多いです。
このへん。
それをさして「イメージだけで書いている」と言ったんですが。

87 ：
>>86
逆にRFC全部みて、ソース全部みて
各々のケースについての解釈と、経路ごとのケースについての解釈をしなければ
イメージだけの記述になる　といいたいのですね
わかりました。まじめに1こ1こ見るためにはどうしたらいいか考えてみることにしましょう。
下記が全部そろえば包括的に検証可能でしょう。
1. solaris本体
　solaris8・・・faxでsolarisのコードを入手
　その他のsolaris・・・入手困難
2. その他の商用unix本体
　入手困難
3. linux本体
　各バージョンをダウンロード
4. *bsd本体
　各バージョンをダウンロード
5.ルータ、スイッチなどの制御ソフト
　入手困難
6. GNU
　各バージョンをダウンロード
7. freeware
　各バージョンをダウンロード
8. 商用パッケージ
　入手困難
9. RFC
　RFCのサイトにてダウンロード

88 ：
>>71 はレイヤがわかってないに一票

89 ：
LayerがわかっててもどうしようもねーYo
どこで何つかってるかはLayer次第なんだし・・・

90 ：
で、結局どうなのよ？アブネーの？危なくネーの？
ひょっとしてまだ世界で誰も実態把握してない？？

91 ：
>>79
めいかいにかいてくれてありがとう。
おかげで、全く理解してないことがよーくわかったよ。
>　→そもそも信頼できない相手から来た郵便をあけるなんていうのは
>　　ユナボナーの犠牲者になりたい団の一員としか思えませんね　自業自得でしょう
送られてきた *.exe を実行するのと、圧縮ファイルを展開するのは
根本的に違います。
> 　→圧縮はヘッダーも圧縮している場合が多いです。
>　都合よくクラックできるコードを埋めこめるようなパケットやセグメントをうまくつくれる確率は
>　低いでしょう　万一クラックされたら、逆に幸運の持ち主なのかも・・
2ch のコンテンツは zlib で圧縮されています。ブラウザは
それを展開してから表示しています。ここで、悪意を持ったひろゆきが、
　展開時にファイルを片っ端から消してしまうような圧縮ファイルを作って、
　2ch 上に置いた。
さぁどうなるでしょう。運・不運の問題でしょうか。

92 ：
>>91
htmlをzlibで圧縮してブラウザに送り返す事と、圧縮ファイルとの関連性は?

93 ：
>>92
ハァ?

94 ：
>→圧縮はヘッダーも圧縮している場合が多いです。
>都合よくクラックできるコードを埋めこめるようなパケットやセグメントをうまくつくれる確率は
>低いでしょう　万一クラックされたら、逆に幸運の持ち主なのかも・・
と、
>2ch のコンテンツは zlib で圧縮されています。ブラウザは
>それを展開してから表示しています。ここで、悪意を持ったひろゆきが、
>　展開時にファイルを片っ端から消してしまうような圧縮ファイルを作って、
>　2ch 上に置いた。
>さぁどうなるでしょう。運・不運の問題でしょうか。
とは想定している部分が違うような。
カーネルレベルなのか、ユーザープロセスレベルの話なのかはっきりさせよう。

95 ：
>>92
ダメだこりゃ。

96 ：
>>91
>さぁどうなるでしょう。運・不運の問題でしょうか。
どうにもならないんじゃないかな？パッチでてるし。
あ、パッチ出してない企業があったねぇ。そいつはやばいかもな。

97 ：
>>94
> カーネルレベルなのか、ユーザープロセスレベルの話なのかはっきりさせよう。
なぜその必要がある?
プロトコルレベルでの圧縮というのは、運・不運に帰着する問題ではないと
言いたかったわけだが、もしかしてユーザプロセスでは運・不運で、カーネルレ
ベルでは違う、と主張したいの?
>>96
> どうにもならないんじゃないかな？パッチでてるし。
> あ、パッチ出してない企業があったねぇ。そいつはやばいかもな。
パッチ当てなきゃファイル消されるかもしれない。よって、zlib の穴は
直すべき問題であって、71 が書いた「利用者側の問題」というのは
的外れだよね。

98 ：
で、結局何がどうなって実害がでそうなの？
スパーハカーの皆さん解説してちょ

99 ：
悪意があれば穴使う必要もないって

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
4月からシステム管理することになったんだけど
替え歌スレ@UNIX板
Autoconf,Automakeについて
懺悔の部屋 (in UNIX板)