5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

zlib大丈夫か

1 :MSおまえもか?:02/03/16 00:06
zlibやってくれたよな〜。
opensshバージョンアップしたとたんにリコンパイルかよ。
MSにまで広がってるのってなんでや?
あいつら密かにオープンソース売ってるんか?

2 :名無しさん@Emacs:02/03/16 00:07
2ゲトズサ


3 :名無しさん@Emacs:02/03/16 00:10
ツイデニ3モゲトズサー

4 :名無しさん@Vim%Chalice:02/03/16 00:14
4ゲットズサー

5 :にせむら りか:02/03/16 00:40



6 :zlib-1.1.3:02/03/16 00:53
もうだめぽ。

7 :名無しさん@お腹いっぱい。:02/03/16 01:24
コンパイル時の利便性取って各アプリで腹持ちしてるからこういう事に
なるんだ。素直にshared libraryをrequireしときゃzlibだけの入れ
替えで済んだのによ。

と煽ってみたり。

8 :電子のお金十箱:02/03/16 01:28
2重freeが問題なので、一部のダサイ実装以外は気にしなくても平気らしい。

# それよりも、このネタでまたfj.comp.lang.cあたりでmalloc & freeが
# 再燃しないか楽しみ。


9 :名無しさん@お腹いっぱい。:02/03/16 01:38
ああ、それで塩兄さんの日記でそのネタやってたのか。
glibcは駄目みたいだね。

10 :名無しさん@お腹いっぱい。:02/03/16 02:22
zlib なんだかわかんないけどどりあえず アプデート してみました。

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
ってか?


12 :名無しさん@お腹いっぱい。:02/03/16 12:25
>>7
kernel 回りもヤバい奴があったりするようだけどな。
ppp 関係とか。


13 :名無しさん@お腹いっぱい。:02/03/16 17:55
スマン、何の話だかサパ-リ分からんのだが、
良かったら誰か解説してくれぬか?

14 :名無しさん@お腹いっぱい。:02/03/16 18:23
>>13

>>10を見習えYO!(w


15 :名無しさん@お腹いっぱい。:02/03/16 18:49
>>11
漏れは djb 信者ぢゃないけど envdir

16 :名無しさん@お腹いっぱい。:02/03/16 18:50
ヴォケの >>13 はすっこんでろ

17 :名無しさん@お腹いっぱい。:02/03/16 19:39
>> 13

厨房なので、間違えているかもしれんが

zlibとは、圧縮用ライブラリである。このライブラリに
セキュリティホールが発見された。


最近のunixは、共有ライブラリを使うもの(多数のプログラム
で同じライブラリを共有する)だが

一部のプログラムは、zlibをstaticでリンクしており、この
弊害の方が今回の騒動で、顕著になった。

rsync,ssh,kernelなどでzlibをつかっている

++++
LD_LIBRARY_PATHの話は、どこからライブラリをロードするか
を決定する話。

glibcの話は、チェックしていないのパス

18 :13:02/03/16 21:27
>>17
ご説明ありがとうございます。
なるほど、staticリンクの問題でしたか。
そう思って読み返してみると意味が分かりました。

厨房にお付き合いの程感謝申し上げまする m(_ _)m

19 :名無しさん@お腹いっぱい。:02/03/16 21:30
>>17
発見されたのはセキュリティホールではなくバグ。
このバグがセキュリティーホールにつながるかどうかは、
他のライブラリに依存する。これが glibc の話に関わってくる。
で、glibc を使ってるシステムはちょっとやばいかも、という話。


20 :名無しさん@お腹いっぱい。:02/03/16 21:40
openbsd神話崩壊ですか?

21 :名無しさん@お腹いっぱい。:02/03/16 21:55
>>20
どういうこと?

22 :名無しさん@お腹いっぱい。:02/03/16 22:27
>>20
「デフォルトの設定で」はpppもipcompもsshも使ってないので
問題ないと思う。(w


23 :login:Penguin:02/03/16 22:30
>>21
> どういうこと?

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


24 :親切な人:02/03/16 22:35

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

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

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

25 :MSおまえもか?:02/03/16 23:00
libpngとかも関係してるし。
ありえんと思うけどIE開いたとたんにワームに感染な〜んて!
あったら怖いな。

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


26 :名無しさん@お腹いっぱい。:02/03/17 00:27
私のところのマシンのOpenSSHはどれも、libzをdynamic linkしてるけど? >>1



27 :外出しとおもうが:02/03/17 12:30
MSはコードをパクっているらしいな。
http://japan.cnet.com/Enterprise/News/2002/Item/020315-5.html?me

28 :名無しさん@お腹いっぱい。:02/03/17 12:43
>>25 ネタ?
ソースからコンパイルしても安全ってわけじゃないんだけど

29 :名無しさん@お腹いっぱい。:02/03/17 13:01
あのさ、漏れ ssh-1.2.27 (クライアント側のみ)使ってんだけどさ。
これ危ないの?
この話に限らないんだけど、
セキュリティーの話ってはっきり言ってもううんざりなんだよ。
そんなの細かいこと気にしてたら気にしなきゃならないことだらけで
やってられん。

30 :マカー:02/03/17 13:31
あの〜OS Xもヤヴァいんでしょうか

31 :MSおまえもか?:02/03/17 13:41
>>25
少なくとも、何をリンクして何をしているかの見分けはつくっしょ。
やばそうなら、入れなきゃいいし、ソースいぢれるし。
C系列が分かんなきゃ話にならんけど。


32 :名無しさん@お腹いっぱい。:02/03/17 13:50
>>28
>>25は全ソースをauditしている
スーパーハッカーです。たぶん。


33 :名無しさん@お腹いっぱい。:02/03/17 13:53
>>9
MALLOC_CHECKに敢えて触れていないワナ。


34 :名無しさん@Emacs:02/03/17 14:02
http://www.gzip.org/zlib/apps.html
DirectX にも zlib が。
うかうかとエロゲもやってられません。

35 :名無しさん@お腹いっぱい。:02/03/17 14:03
>>34
心配するなよ。

36 :名無しさん@お腹いっぱい。:02/03/17 14:06
FreeBSDとかは2重解放はデフォルトでチェックするけど、
char *buf=malloc(100);
free(buf);
buf[10] = 10;
なんてコードには約立たずなのはどこもいっしょ。


37 :名無しさん@お腹いっぱい。:02/03/17 14:22
>>36
ん?そういうコードが zlib に含まれてるの?

38 :名無しさん@お腹いっぱい。:02/03/17 14:39
っていうか大騒ぎしすぎな気がする

39 :名無しさん@お腹いっぱい。:02/03/17 14:46
もちろん一般論だYO。

40 :名無しさん@お腹いっぱい。:02/03/17 14:56
>>39
あんまりむやみに話膨らますなYO!
(特に malloc() & free() 話は)

41 :名無しさん@お腹いっぱい。:02/03/17 15:38
だれか>>26に答えてくれ。


42 :login:Penguin:02/03/17 15:57
>>41
反語は強調やほのめかしに使うもんで、答える対象じゃないだろ?
↑この文に答えるなよ。


43 :名無しさん@お腹いっぱい。:02/03/17 16:10
>>1 のいみがよくわからんってことでしょう


44 :名無しさん@お腹いっぱい。:02/03/17 16:17
>>42は反語の意味がわかっているのだろうか?(いやわかっていない)

45 :名無しさん@お腹いっぱい。:02/03/17 16:20
zlib になにがあったの?

46 :名無しさん@Emacs:02/03/17 16:21
つーか、GPL適用しとけば、MSがソースコカーイとかあったかもしれないのに。
ザンネソ。

47 :名無しさん@お腹いっぱい。:02/03/17 16:28
もしGPLだったら、使わずにスクラッチから実装するだけでしょ。

48 :名無しさん@お腹いっぱい。:02/03/17 16:33
>>47
で、実装バグにより(以下略)

49 :名無しさん@お腹いっぱい。:02/03/17 16:51
>>48
しかも独自拡張部分で(以下略)

50 :名無しさん@お腹いっぱい。:02/03/17 17:35
>>48
zlib相当を作るときはまともなプログラマ使うだろ。
MSのプログラマはスーパーハカーから超ヘタレまで格差ありすぎ(w


51 :名無しさん@お腹いっぱい。:02/03/17 18:17
>>50
では今回のzlib問題はMSについては問題ないとゆーことですね。
スーパーハカーがまともなzlib互換libを作ったんでしょ?(w

52 :名無しさん@お腹いっぱい。:02/03/17 18:23
>>51
はいはいそうですよ。読解け。

53 :名無しさん@お腹いっぱい。:02/03/19 01:05
>> 29

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

54 :名無しさん@お腹いっぱい。:02/03/19 04:54
kernel内部の libzとかは大丈夫なんでしょうか? >>お前ら
free(3) は大丈夫でも free(9) で商店とかありませんか?
いや、sourceをちっとも見ないでいってるんですけど。


55 :名無しさん@お腹いっぱい。:02/03/19 10:28
>>54
今回の問題の根本はdouble freeという現象であって、意図的に加工された
.gzファイルを展開しようとしたときに意図しないコードが実行する可能性
がある、というもの。

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


56 :名無しさん@お腹いっぱい。:02/03/19 11:14
>54
通信のデータとかをカーネル内部で圧縮していたら?

57 :名無しさん@お腹いっぱい。:02/03/19 11:39
>>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
FreeBSD と OpenBSD はパッチでたね。

59 :名無しさん@お腹いっぱい。:02/03/19 19:36
XFree86-4.2.0も出てまっせ。

60 :kcrt:02/03/19 21:22
MSはコード公開しる!

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

61 :名無しさん@お腹いっぱい。:02/03/19 21:44
>>60
ソースが汚ないってよく言うけど、具体的にはどんなの?
≒読み難い(eg. qmail)ってことでいいんでしょうか。


62 :名無しさん@お腹いっぱい。:02/03/19 21:48
>>60はつねにきれいなコードを書く神あるいはしろうと。

63 :kcrt=60:02/03/19 21:53
汚い=MFCのコード。なんか、あれ構造おかしくない?

64 :名無しさん@お腹いっぱい。:02/03/19 22:25
MFC は別になんとも思わなかったが...
俺が鈍感なだけ?


65 :名無しさん@お腹いっぱい。:02/03/19 23:17
MFCは問題ないんでない?

66 :login:Penguin:02/03/20 00:02
MFCのソースコードは読んだことないが、
クラス階層がしょぼい

67 :名無しさん@お腹いっぱい。:02/03/20 00:02
>>61
breakflag = 0;

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

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

}

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

見たいなのをいふんだYO!

68 :名無しさん@お腹いっぱい。:02/03/20 00:11
>>67
gotoとかMSが使わせるとは思えんが。

69 :名無しさん@お腹いっぱい。:02/03/20 09:39
>>60
MS=ソース汚い, ってのは短絡的じゃない?
あー、外部から分かる動作でソースコードの汚さが
推測できる、のかもしれないが。

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

70 :login:Penguin:02/03/20 09:52
CMUとかMITとかも持ってるよ。
今やNTはMicrosoftのコードだけで動いているわけではないし。メーカも書いてる。

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

71 :名無しさん@お腹いっぱい。:02/03/20 11:51
中でzlibつかって圧縮かけてやってるロジックがあったとしても、
展開対象のデータに悪意のあるデータが入っている場合のみ穴になる、と。

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

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

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

72 :名無しさん@お腹いっぱい。:02/03/20 12:23
>>71
> 利用者問題だわな。

んなアホな。

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


73 :名無しさん@お腹いっぱい。:02/03/20 12:55
>>71 はイメージだけで書いてるに1票。


74 :名無しさん@お腹いっぱい。:02/03/20 13:20
漏れ、自己解凍のLHAやZIP形式の*.exeファイルもらった時も、
UNIX上でlhaやunizpで直接解凍して、
決してWin上で実行しないようにしてる。
でもそれでも安全ではなくなるのか…

75 :アフォ?:02/03/20 15:51
>>74
> でもそれでも安全ではなくなるのか…

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



76 :名無しさん@お腹いっぱい。:02/03/20 23:37
>>74
ふつうに win 上で unzip とか lha で
解凍すればいいのでは????
なぜわざわざ UNIX 上でやるのか、
そして zip や lha はスレ違いなこと、
なにもかもが わけわからん(w


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

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

78 :名無しさん@お腹いっぱい。:02/03/21 00:23
>>77
> つか、自明の理しかかいとらんのだが・・・いったいどーかけというのやら。

明快に簡潔に書く。

79 :71:02/03/21 02:38
じゃ めいかいにかく

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

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


80 :名無しさん@お腹いっぱい。:02/03/21 03:02
そんな幸運うれしくないYO!

81 :名無しさん@お腹いっぱい。:02/03/21 03:07
>>74 解凍ができるのはlhaだけ…

82 :名無しさん@お腹いっぱい。:02/03/21 05:22
つーか自己解凍式書庫は今回のzlib云々とは無関係の所でもリスクはあるんだが
(自己展開部分になんか仕込まれてるとか)

83 :名無しさん@お腹いっぱい。:02/03/21 08:56
>>81
zipもできるよ。

84 :名無しさん@お腹いっぱい。:02/03/21 08:59
>>83 (゚Д゚)ハァ?

85 :名無しさん@お腹いっぱい。:02/03/21 10:42
>>83
http://www3.justnet.ne.jp/~s_kishimoto/fj/misc/fj-words.htm#KAITO_

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


87 :71:02/03/21 18:31
>>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 :名無しさん@お腹いっぱい。:02/03/22 18:05
>>71 はレイヤがわかってないに一票


89 :名無しさん@お腹いっぱい。:02/03/24 06:38
LayerがわかっててもどうしようもねーYo
どこで何つかってるかはLayer次第なんだし・・・


90 :名無しさん@お腹いっぱい。:02/03/24 19:01
で、結局どうなのよ?アブネーの?危なくネーの?
ひょっとしてまだ世界で誰も実態把握してない??

91 :名無しさん@お腹いっぱい。:02/03/24 20:44
>>79
めいかいにかいてくれてありがとう。

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

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

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

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

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


92 :名無しさん@お腹いっぱい。:02/03/24 21:11
>>91
htmlをzlibで圧縮してブラウザに送り返す事と、圧縮ファイルとの関連性は?


93 :名無しさん@お腹いっぱい。:02/03/24 21:12
>>92
ハァ?

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

95 :名無しさん@お腹いっぱい。:02/03/24 21:33
>>92
ダメだこりゃ。

96 :名無しさん@お腹いっぱい。:02/03/24 21:39
>>91
>さぁどうなるでしょう。運・不運の問題でしょうか。
どうにもならないんじゃないかな?パッチでてるし。
あ、パッチ出してない企業があったねぇ。そいつはやばいかもな。

97 :91:02/03/24 23:12
>>94
> カーネルレベルなのか、ユーザープロセスレベルの話なのかはっきりさせよう。

なぜその必要がある?

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

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

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


98 :名無しさん@お腹いっぱい。:02/03/24 23:45
で、結局何がどうなって実害がでそうなの?
スパーハカーの皆さん解説してちょ

99 :名無しさん@XEmacs:02/03/25 00:30
悪意があれば穴使う必要もないって

100 :名無しさん@お腹いっぱい。:02/03/25 01:42
オイオーイ、結局誰も実害について何も言えないのか??


101 :名無しさん@お腹いっぱい。:02/03/25 01:43
やっぱこんなとこ荒らしに荒らされて当然だな。

102 :名無しさん@お腹いっぱい。:02/03/25 01:43
一番現実に即した意見が
「パッチあてろ」かよ・・・お笑いだ

103 :名無しさん@お腹いっぱい。:02/03/25 02:04
実害無いに等しいからね。今んとこ。

104 :名無しさん@お腹いっぱい。:02/03/25 02:11
>>101
キミがあらゆるプロトコルで試してみて、穴があったらそれが危機というものだ。
文句言う前に探してみなよ。


105 :名無しさん@Emacs:02/03/25 03:52
ユナボマー

106 :名無しさん@お腹いっぱい。:02/03/25 07:46
>>102
自分で調べられんのか。
お笑いだ。


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

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

108 :名無しさん@お腹いっぱい。:02/03/25 23:17
>>107
> ・OpenBSDは1月にすでに直していたらしい、、、報告してくれよぉ〜
前もあったな、そんなこと。
http://www.lac.co.jp/security/intelligence/CERT/CA-2001_02.html

109 :名無しさん@お腹いっぱい。:02/10/17 19:06
なめこ

110 :山崎渉:03/01/15 13:27
(^^)

111 :名無しさん@お腹いっぱい。:03/03/14 01:43
ぬるぽ

112 :名無しさん@お腹いっぱい。:03/03/14 13:43
http://www.securityfocus.com/bid/6913

113 :名無しさん@お腹いっぱい。:03/03/14 18:10
もうコンパイルし直すのは嫌ぽ。

114 :名無しさん@お腹いっぱい。:03/03/14 18:15
>>113
年一回くらいいいじゃん。

115 :名無しさん@Emacs:03/03/14 18:22
>111
ガッ


116 :山崎渉:03/04/17 12:19
(^^)

117 :あぼーん:あぼーん
あぼーん

118 :あぼーん:あぼーん
あぼーん

119 :あぼーん:あぼーん
あぼーん

120 :あぼーん:あぼーん
あぼーん

121 :名無しさん@お腹いっぱい。:04/10/08 21:36:55
大丈夫だ!

122 :名無しさん@お腹いっぱい。:2005/07/07(木) 19:10:39
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096


123 :名無しさん@お腹いっぱい。:2005/07/07(木) 21:47:06
read.cgiは順調か?

124 :名無しさん@お腹いっぱい。:2005/07/20(水) 13:02:51
1.2.3 キタ━━━━(゜∀゜)━━━━!!

ttp://sourceforge.net/project/showfiles.php?group_id=5624&package_id=14274&release_id=343023



125 :名無しさん@お腹いっぱい。:2005/07/20(水) 14:12:25
>>124 age

126 :名無しさん@お腹いっぱい。:2005/07/20(水) 20:44:36
キタキタキタキタ━━━(゚∀゚≡(゚∀゚≡゚∀゚)≡゚∀゚)━━━━!!
Changes in 1.2.3 (18 July 2005)
- Apply security vulnerability fixes to contrib/infback9 as well
- Clean up some text files (carriage returns, trailing space)
- Update testzlib, vstudio, masmx64, and masmx86 in contrib [Vollant]


127 :名無しさん@お腹いっぱい。:2005/07/25(月) 09:04:39
OOo のソースツリーを見せてもらったが、zlib なんかもスタティックリンクしている模様。

128 :名無しさん@お腹いっぱい。:2005/07/27(水) 18:58:31
またセキュリティホールなのか?
Index: lib/libz/inftrees.h
===================================================================
RCS file: /home/ncvs/src/lib/libz/inftrees.h,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 inftrees.h
--- lib/libz/inftrees.h 30 Jun 2004 23:43:27 -0000 1.1.1.5
+++ lib/libz/inftrees.h 23 Jul 2005 13:08:30 -0000
@@ -36,12 +36,12 @@
*/

/* Maximum size of dynamic tree. The maximum found in a long but non-
- exhaustive search was 1004 code structures (850 for length/literals
- and 154 for distances, the latter actually the result of an
+ exhaustive search was 1444 code structures (852 for length/literals
+ and 592 for distances, the latter actually the result of an
exhaustive search). The true maximum is not known, but the value
below is more than safe. */
-#define ENOUGH 1440
-#define MAXD 154
+#define ENOUGH 2048
+#define MAXD 592

/* Type of code to build for inftable() */
typedef enum {


129 :名無しさん@お腹いっぱい。:2006/05/27(土) 17:05:56
テスト

130 :名無しさん@お腹いっぱい。:2006/07/15(土) 18:58:17
○/'ー´ヽ
  (, `●´ )
〜( O┯O
(☆)ヽ_/(★)


131 :名無しさん@お腹いっぱい。:2006/07/15(土) 18:59:02
、、、  ○/'ー´ヽ
、、.≡≡ (, `●´ )
、、≡≡〜( O┯O
、、≡ (☆)ヽ_/(★)

132 :名無しさん@お腹いっぱい。:2006/07/19(水) 23:56:13
頑張って走りきるんだよもん


133 :名無しさん@お腹いっぱい。:2006/07/27(木) 04:27:30
>>1-132
zzzzzzlib

134 :名無しさん@お腹いっぱい。:2006/08/10(木) 20:41:59
気象庁(大手町)の1Fにある本屋「津村書店」についての裏事情

ここにいる70歳くらいの、頭の完全に禿げた眼鏡をかけたジジイは、とにかく短気かつ凶暴である。
以下にこのジジイの悪行を、一部であるが記す。

・まず、本屋で5分以上うろついていると、「何か買いたい物があるか」と突慳貪に言い、
黙っているか、「いいえ」とか言うと、「買う気がないなら、出て行け」と言う。
・次に、立ち読みでもしていようなら、腕をつかんだ上で、奥に連れて行き、殴る蹴るの暴行を
加える。過去に顔にあざができたり、鼻血が出たりしたケースもあったらしい。また、女性の場合
胸を揉むなどの、セクハラをしたこともあったとか。
・一見ひ弱そうに見えるが、実は、柔道黒帯,合気道二段の腕前。そして、足も速い(笑)
・そして、納品作業をしていると、客がいようがお構いなしに「そこ邪魔だ、どかんかい」
と怒り、睨み付ける。(場合によっては足で蹴る)ちなみに店内は非常に狭い。そして本の陳列も非常に雑。
・極め付けは、清算をする時。例えば320円の雑誌を買って、1020円を出そうものなら
「何故1000円札一枚で出さない?計算しにくいんだよ、アホンダラ」と言って、20円分を投げる。また、お釣りは投げるようにして、渡される。

ここの本屋は、マニアックな本は多いが、品揃えは悪い。そして、何と言っても、上記のように主人の
接客態度が最悪。
こんな本屋で買い物をするのは、極力避けた方が良いとアドバイスしておく。

135 :名無しさん@お腹いっぱい。:2006/08/13(日) 13:34:09
test

136 :名無しさん@お腹いっぱい。:2006/08/13(日) 13:35:18
test

31 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)