zlib大丈夫か

[1 MSおまえもか？ NG NG]

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

[22 名無しさん＠お腹いっぱい。 NG NG]

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

[23 login:Penguin NG NG]

>>21
> どういうこと？

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

[24 親切な人 NG NG]

ヤフーオークションで、凄い人気商品、発見！！！

「高性能ビデオスタビライザー」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

[25 MSおまえもか？ NG NG]

libpngとかも関係してるし。
ありえんと思うけどIE開いたとたんにワームに感染な〜んて！
あったら怖いな。

けど、sunsiteとかからパッケージダウンロードしてる最近の
サーバモンキーとかいう奇特なお方は知らぬ間にセキュリティー
ホール作ってるてことだよなぁ。
実はそういうお方が一番怖いと思うね。俺わ。

[26 名無しさん＠お腹いっぱい。 NG NG]

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

[27 外出しとおもうが NG NG]

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

[28 名無しさん＠お腹いっぱい。 NG NG]

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

[29 名無しさん＠お腹いっぱい。 NG NG]

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

[30 マカー NG NG]

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

[31 MSおまえもか？ NG NG]

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

[32 名無しさん＠お腹いっぱい。 NG NG]

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

[33 名無しさん＠お腹いっぱい。 NG NG]

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

[34 名無しさん＠Ｅｍａｃｓ NG NG]

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

[35 名無しさん＠お腹いっぱい。 NG NG]

>>34
心配するなよ。

[36 名無しさん＠お腹いっぱい。 NG NG]

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

[37 名無しさん＠お腹いっぱい。 NG NG]

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

[38 名無しさん＠お腹いっぱい。 NG NG]

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

[39 名無しさん＠お腹いっぱい。 NG NG]

もちろん一般論だYO。

[40 名無しさん＠お腹いっぱい。 NG NG]

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

[41 名無しさん＠お腹いっぱい。 NG NG]

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

[42 login:Penguin NG NG]

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

[43 名無しさん＠お腹いっぱい。 NG NG]

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

[44 名無しさん＠お腹いっぱい。 NG NG]

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

[45 名無しさん＠お腹いっぱい。 NG NG]

zlib になにがあったの？

[46 名無しさん＠Ｅｍａｃｓ NG NG]

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

[47 名無しさん＠お腹いっぱい。 NG NG]

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

[48 名無しさん＠お腹いっぱい。 NG NG]

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

[49 名無しさん＠お腹いっぱい。 NG NG]

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

[50 名無しさん＠お腹いっぱい。 NG NG]

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

[51 名無しさん＠お腹いっぱい。 NG NG]

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

[52 名無しさん＠お腹いっぱい。 NG NG]

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

[53 名無しさん＠お腹いっぱい。 NG NG]

>> 29

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

[54 名無しさん＠お腹いっぱい。 NG NG]

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

[55 名無しさん＠お腹いっぱい。 NG NG]

>>54
今回の問題の根本はdouble freeという現象であって、意図的に加工された
.gzファイルを展開しようとしたときに意図しないコードが実行する可能性
がある、というもの。

従って、カーネルのように信頼できるものを展開する際にはセキュリティ上
の問題になることはないはず。例外として発信元不明な謎のカーネル（また
はモジュール）をコンパイルしてインストールすればセキュリティホールを
突くこともできるが、そんな面倒なことをやるくらいならそのカーネルか
モジュールのソースそのものに穴を用意すればいいだけのことだし、何より
も信頼できないソースを利用すること自身が既に問題。

[56 名無しさん＠お腹いっぱい。 NG NG]

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

[57 名無しさん＠お腹いっぱい。 NG NG]

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

[58 名無しさん＠お腹いっぱい。 NG NG]

FreeBSD と OpenBSD はパッチでたね。

[59 名無しさん＠お腹いっぱい。 NG NG]

XFree86-4.2.0も出てまっせ。

[60 kcrt NG NG]

MSはコード公開しる！

・・・あ、汚いWind*wsのコードとか見せられると使う気なくすなぁ

[61 名無しさん＠お腹いっぱい。 NG NG]

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

[62 名無しさん＠お腹いっぱい。 NG NG]

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

[63 kcrt=60 NG NG]

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

[64 名無しさん＠お腹いっぱい。 NG NG]

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

[65 名無しさん＠お腹いっぱい。 NG NG]

MFCは問題ないんでない？

[66 login:Penguin NG NG]

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

[67 名無しさん＠お腹いっぱい。 NG NG]

>>61
breakflag = 0;

for( なんかループ　){
for( なんかループ　){

if(なんか条件){
breakflag = 1;
goto NASTY;
}
}

}

NASTY:
if(breakflag){
なんかさいあくなしょり
}

見たいなのをいふんだＹＯ！

[68 名無しさん＠お腹いっぱい。 NG NG]

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

[69 名無しさん＠お腹いっぱい。 NG NG]

>>60
MS=ソース汚い, ってのは短絡的じゃない?
あー、外部から分かる動作でソースコードの汚さが
推測できる、のかもしれないが。

# 大学にNTのソースライセンス提供したとかいう話もあったな。慶応だったか。
# ここに読んだことがあるやついるかな。

[70 login:Penguin NG NG]

CMUとかMITとかも持ってるよ。
今やNTはMicrosoftのコードだけで動いているわけではないし。メーカも書いてる。

SEGAに来たCEのソースは厨房レベルだったって。
コーディングスタイルが汚いとかどうかという以前に、
アルゴリズム、OSの基礎知識がない奴がコーディングにかり出された感じらしい。

[71 名無しさん＠お腹いっぱい。 NG NG]

中でzlibつかって圧縮かけてやってるロジックがあったとしても、
展開対象のデータに悪意のあるデータが入っている場合のみ穴になる、と。

第三者から渡されたtar玉になんか仕組んであったとしても、
それはWindowsでいうところの
"exeファイルがついてあるときは、相手にそのファイルをどう扱ったらいいか聞いて対処しなさい"
問題と同じであるから、利用者問題だわな。

プロトコルスタック内部で圧縮展開なんかやってる部分に関しては、
そういうデータと同じデータの並びになるようなデータ列を処理したときのみ起こり得る。

うまくそういうIPパケットを流すことができるのであれば、それはそれで穴にはなるだろうが、
せいぜい経路上の次のノードに対してそういうのを流すことができる程度か？
ヘッダー内容とそういう並びのデータ列とがうまくマッチするケースがあるかどうかで
可能かどうかわかるんじゃろーけんど。（まあありえんか・・・）

[72 名無しさん＠お腹いっぱい。 NG NG]

>>71
> 利用者問題だわな。

んなアホな。

そんなことを言ったら、圧縮するプロトコル (HTTP とか PPP とか) は
成り立たないじゃん。

[73 名無しさん＠お腹いっぱい。 NG NG]

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

[74 名無しさん＠お腹いっぱい。 NG NG]

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

[75 アフォ? NG NG]

>>74
> でもそれでも安全ではなくなるのか…

つーか、「漏れ」の話なら、安全にすればいいじゃん。まだやってないの?

[76 名無しさん＠お腹いっぱい。 NG NG]

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

[77 71 NG NG]

>>72-73
プロトコルスタック中でのzlib利用時に懸念されることがらも併記してしてんのに
イメクラ状態レスなんかいな。

つか、自明の理しかかいとらんのだが・・・いったいどーかけというのやら。

[78 名無しさん＠お腹いっぱい。 NG NG]

>>77
> つか、自明の理しかかいとらんのだが・・・いったいどーかけというのやら。

明快に簡潔に書く。

[79 71 NG NG]

じゃ　めいかいにかく

・圧縮されたファイルをもらいました　どうしよう？（どうしよう？）
　→そもそも信頼できない相手から来た郵便をあけるなんていうのは
　　　ユナボナーの犠牲者になりたい団の一員としか思えませんね　自業自得でしょう

・通信のなかで圧縮展開してる部分がありますよね？
　ヘンなデータでつつかれてクラックされたりしたらどうしよう？（どうしよう？）
　→圧縮はヘッダーも圧縮している場合が多いです。
　　都合よくクラックできるコードを埋めこめるようなパケットやセグメントをうまくつくれる確率は
　　低いでしょう　万一クラックされたら、逆に幸運の持ち主なのかも・・・

[80 名無しさん＠お腹いっぱい。 NG NG]

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

[81 名無しさん＠お腹いっぱい。 NG NG]

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

[82 名無しさん＠お腹いっぱい。 NG NG]

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

[83 名無しさん＠お腹いっぱい。 NG NG]

>>81
zipもできるよ。

[84 名無しさん＠お腹いっぱい。 NG NG]

>>83 (ﾟДﾟ)ﾊｧ?

[85 名無しさん＠お腹いっぱい。 NG NG]

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

[86 73 NG NG]

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

[87 71 NG NG]

>>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 名無しさん＠お腹いっぱい。 NG NG]

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

[89 名無しさん＠お腹いっぱい。 NG NG]

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

[90 名無しさん＠お腹いっぱい。 NG NG]

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

[91 名無しさん＠お腹いっぱい。 NG NG]

>>79
めいかいにかいてくれてありがとう。

おかげで、全く理解してないことがよーくわかったよ。

>　→そもそも信頼できない相手から来た郵便をあけるなんていうのは
>　　ユナボナーの犠牲者になりたい団の一員としか思えませんね　自業自得でしょう

送られてきた *.exe を実行するのと、圧縮ファイルを展開するのは
根本的に違います。

> 　→圧縮はヘッダーも圧縮している場合が多いです。
>　都合よくクラックできるコードを埋めこめるようなパケットやセグメントをうまくつくれる確率は
>　低いでしょう　万一クラックされたら、逆に幸運の持ち主なのかも・・

2ch のコンテンツは zlib で圧縮されています。ブラウザは
それを展開してから表示しています。ここで、悪意を持ったひろゆきが、
　展開時にファイルを片っ端から消してしまうような圧縮ファイルを作って、
　2ch 上に置いた。
さぁどうなるでしょう。運・不運の問題でしょうか。

[92 名無しさん＠お腹いっぱい。 NG NG]

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

[93 名無しさん＠お腹いっぱい。 NG NG]

>>92
ハァ?

[94 名無しさん＠お腹いっぱい。 NG NG]

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

[95 名無しさん＠お腹いっぱい。 NG NG]

>>92
ダメだこりゃ。

[96 名無しさん＠お腹いっぱい。 NG NG]

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

[97 91 NG NG]

>>94
> カーネルレベルなのか、ユーザープロセスレベルの話なのかはっきりさせよう。

なぜその必要がある?

プロトコルレベルでの圧縮というのは、運・不運に帰着する問題ではないと
言いたかったわけだが、もしかしてユーザプロセスでは運・不運で、カーネルレ
ベルでは違う、と主張したいの?

>>96
> どうにもならないんじゃないかな？パッチでてるし。
> あ、パッチ出してない企業があったねぇ。そいつはやばいかもな。

パッチ当てなきゃファイル消されるかもしれない。よって、zlib の穴は
直すべき問題であって、71 が書いた「利用者側の問題」というのは
的外れだよね。

[98 名無しさん＠お腹いっぱい。 NG NG]

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

[99 名無しさん＠ＸＥｍａｃｓ NG NG]

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

[100 名無しさん＠お腹いっぱい。 NG NG]

オイオーイ、結局誰も実害について何も言えないのか？？

[101 名無しさん＠お腹いっぱい。 NG NG]

やっぱこんなとこ荒らしに荒らされて当然だな。

[102 名無しさん＠お腹いっぱい。 NG NG]

一番現実に即した意見が
「パッチあてろ」かよ・・・お笑いだ

[103 名無しさん＠お腹いっぱい。 NG NG]

実害無いに等しいからね。今んとこ。

[104 名無しさん＠お腹いっぱい。 NG NG]

>>101
キミがあらゆるプロトコルで試してみて、穴があったらそれが危機というものだ。
文句言う前に探してみなよ。

[105 名無しさん＠Ｅｍａｃｓ NG NG]

ユナボマー

[106 名無しさん＠お腹いっぱい。 NG NG]

>>102
自分で調べられんのか。
お笑いだ。

[107 名無しさん＠お腹いっぱい。 NG NG]

なぜ荒れるのか理解に苦しむが・・・事実を整理すると
・zlibに2重開放bugがみつかった
・bugをみつけたRedhatのエンジニアの発表では
「穴になる可能性がある」
「でもウィルスを作るにはかなり手がかかるだろう」
「まだウィルスはみつかってないが、アングラで出回ってるかもしれない」
・2重開放をチェックしてるシステム(FreeBSDなど)は大丈夫そうだ
・パッチはすでにあるので当てればOK
・静的リンクしてるオブジェクトを探し出すのは大変だよぉ
・カーネルでもPPP関係で修正パッチがでている(Linuxや*BSD。Winは知らん)
・この穴を使ったウィルスはまだ見つかってない
てとこかな？間違ってたら訂正お願い。

俺が？と思ってるのは・・・
・OpenBSDは1月にすでに直していたらしい、、、報告してくれよぉ〜
・glibcは2重開放をチェックしてない、、、仕様としてどちらが良いのかよくわからん
・お金を取ってる企業の対応が遅いのはやっぱり納得できん

[108 名無しさん＠お腹いっぱい。 NG NG]

>>107
> ・OpenBSDは1月にすでに直していたらしい、、、報告してくれよぉ〜
前もあったな、そんなこと。
http://www.lac.co.jp/security/intelligence/CERT/CA-2001_02.html

[109 名無しさん＠お腹いっぱい。 NG NG]

なめこ

[110 山崎渉 NG NG]

（＾＾）

[111 名無しさん＠お腹いっぱい。 NG NG]

ぬるぽ

[112 名無しさん＠お腹いっぱい。 NG NG]

http://www.securityfocus.com/bid/6913

[113 名無しさん＠お腹いっぱい。 NG NG]

もうコンパイルし直すのは嫌ぽ。

[114 名無しさん＠お腹いっぱい。 NG NG]

>>113
年一回くらいいいじゃん。

[115 名無しさん@Eｍａｃｓ NG NG]

>111
ｶﾞｯ

[116 山崎渉 NG NG]

（＾＾）

[117 あぼーん NG NG]

あぼーん

[118 あぼーん NG NG]

あぼーん

[119 あぼーん NG NG]

あぼーん

[120 あぼーん NG NG]

あぼーん

[121 名無しさん＠お腹いっぱい。 NG NG]

大丈夫だ！