1read 100read
2011年10月1期LinuxLinuxはﾊﾞｯﾌｧｵｰﾊﾞｰﾌﾛｰの悪夢から解放されるか？ TOP カテ一覧 スレ一覧 削除依頼 ▼
・　次のスレ
Linuxを売りにしてる会社について
Linux使いが使っているソフトと満足度
FVWM スレッド
Canna すれ 2頁目【かんな】


Linuxはﾊﾞｯﾌｧｵｰﾊﾞｰﾌﾛｰの悪夢から解放されるか？


1 ：03/12/09 〜 最終レス ：09/06/10
Windowsは基本APIが.NET(WinFX)になって、
少なくとも新APIと.NETを使っている限りは、
OSもユーザアプリもバッファオーバーフローの
悪夢から解放されますよ。
Linuxはどうですか？

2 ：
糞を食べます

3 ：
糞を食べます

4 ：
>>1
とりあえず、書いている内容の根拠を教えて。
君が単なる無知なら削除依頼を出しておいてね。

5 ：
>>1
IDがNT

6 ：
おぉ。すげーぜNT。
>>4
根拠も何も、強力なメモリ管理機能のおかげで、
バッファあふれたくらいで不正なデータ領域に
コード書くことなんかできませんよ。
出来るというのならそれを証明するコードをおねがいします。

7 ：
>>6
君には難しすぎたか…
＞強力なメモリ管理機能
「この根拠を示せ」と言っているんです。わかりますか？
わからんなら削除依頼出せよ。
あ、もしかして、
　「MSのプログラムにバグや設計ミスなどない」
　「宣伝広告まんせー」
って信仰しているタイプ？

8 ：
>>7
出来るというのならそれを証明するコードをおねがいします。

9 ：
>>1 が単なる馬鹿だとわかったので、オレはしばらく放置orROMします。

10 ：
>>9
さようなら。もうこなくていいから。
さて本題。
Linuxではバッファオーバーフロー対策はどうですか？
システムレベルな本格的な対策の導入の予定はありませんか？
まだプログラマがちょっと気を抜くだけで大きなセキュリティ
ホールになる恐れがあるんですか？

11 ：
>>10
バッファオーバーフローに限って言えば、パッチ出てるじゃん遥か前から。

12 ：
頭の可哀想な奴が居る

13 ：
そもそもCでgetsやsprintfなんぞを使うのが原因だろ。
みんなgcc-3に移行してSTLとboost使いまくればよい。
無制限で可変長バッファ取って、
ユーザーの設定を超えたら例外が飛ぶだけだ。

14 ：
先に「MSの.NETがどーたらだからメモリ管理があーだこーだ」のソースを出さないと誰も何を言って良いかわからん。
聞くなら先に自分の根拠。
情報のソース（どこかのニュースwebにリンクを張るとか）を提示してくれ。
話はそれからだ。
このスレがクソで終わるか名スレになるかはディスプレイの前の>>1次第だ。
じゃ、期待してないががんばれ。

15 ：
XPSP2でメモリ保護機能が付く記事がMSにあったが.NETとは関係ないぞ。

16 ：
どうせ例外はくか、OSにクラッシュさせられるだけだろ？
最初からちゃんと動くプログラムかけよ。無能が。

17 ：
まぁでも折角i386系はDSとCS区別できるような構造になってるんだから、
そろそろコード空間とデータ空間分けてもいいよな。
DS上でコード実行（バッファオーバーフロー）しようとしたら例外発生
させりゃいい訳だし。
過去の互換以外に何か問題ある？

18 ：
>>16
だからぁ、CGIでパスワード100文字のフォーム作っても
スクリプト廚が一億文字投げて来るわけだ。
この場合、プロセスを落としてしまえばいいだろ。
リロードすれば復活するわけだし、
F5レベルの攻撃は可能だがrootを取られることはない。

19 ：
はぁ？１億字を適切に処理しろよ？なんでプロセスが落とされる必要があるわけ？

20 ：
>>18
デーモン側で制限出来るだろ。

21 ：
>>17
最初から固定長バッファ切らなきゃ、CSに書かないだろ？
全部可変長配列が正解。
try {
　 string s, buff;
　 while (file.good()) {
　 getline(file, buff);
　 s += buff;
　}
} catch (bad_alloc) {
logging("メモリーがふそくしますた:きます");
exit(0);
}

22 ：
専門的なことを書いても >1 には理解できない気がするのですが…
理解できなくても問題ないけど。

23 ：
ネタスレで真面目に議論する
↓
削除されない
↓
>>1の空age天国

24 ：
>>23
オレは >1 はマジだと思う。無知で傲慢なだけ。
スレ立てた人がアフォでも、まぐれで良スレになることも希にありますよ。

25 ：
>>17
> まぁでも折角i386系はDSとCS区別できるような構造になってるんだから、
> そろそろコード空間とデータ空間分けてもいいよな。
既にOpenBSDは実現していますが、何か?
ttp://www.openbsd.org/papers/pacsec03/j/
そもそもセグメント単位でしか実行の許可が与えられないのが
i386アーキテクチャのダメな所。
ページ単位で実行許可を制御できるsparcなどのほうが
よっぽど楽にコード空間とデータ空間の分離を行なえる。

26 ：
>>25
リンク先がいま一つだな。
ちゃんとしたリンクキボン。

27 ：
で、>>1 はやっぱりアレだったの？

28 ：
誘導
☆Linux カーネルの仕組みを勉強するスレ☆
http://pc.2ch.net/test/read.cgi/linux/1002012247/
どうすりゃいいんだ！Linuxのセキュリティ
http://pc.2ch.net/test/read.cgi/linux/1060840105/

29 ：
スタック上に配列を切らない。

30 ：
トップダウンパーサは当然スタックを消費するし、
bisonもallocaで消費するんで、
これらを使用するインタプリター系で
ユーザーの入力を評価したりSSI的な動作するやつも穴がありそ。
埋め込みrubyみたいなので式が書けるのとか。

31 ：
>>21
バッファオーバーフローを防ぐしくみとしてはそれだな。
だが仮にバッファオーバーフローが起こったとしても
コード実行はされない安全策は>>17
既存のコードをすべて>>21に修正するなんてできないし。
>>25
OpenBSDすばらしい！
Linuxも2.6あたりで実現という話はないの？

32 ：
.NETはJavaVMのようなもんだから。VMによるメモリ管理とか、ベリファイアでコードチェック
とか、同じようにやるね。ちゅーか、VisualJ++開発やってたHejlsberg
がJavaの有用性に目を向けて、MSにああいう仕様にさせたんだろけど。
という能書きはいいとして、
実際にIISやSQLServer,IEがmanagedなコードで書かれるのか、そういうのが気になるね。
それやれば、かなりセキュアにあるだろうけど。パフォーマンスは落ちるだろうけど。
linuxでは、
http://www.research.avayalabs.com/project/libsafe/
とか、使ってるのかな？
OpenBSDの記事、x86用コードはあー、出来てるの？
http://www.zdnet.co.jp/news/0304/15/ne00_openbsd.html

33 ：
>.NETはJavaVMのようなもんだから
スタックの使い方は違う。
オブジェクト自体をスタック上にも置けるのが.NET

34 ：
>>33
structの場合ね。しかし、それは些事だなあ。

35 ：
実際にIISとかが.netベースで書かれたら圧倒的にパフォーマンス落ちるだろうね
んで誰も使わなくなるだろうね。

36 ：
>>32
libsafe は static リンクしてると使えない、っていう欠点があったはずじゃ？
preload が上手く働かんかったような。詳細きぼんぬ。
OpenBSD の場合、>>32 で例示されてる物以外にもセキュリティを確保する仕組みが
色々あって、任意のコードが実行される可能性は極端に低いと思う。
>>35
そんなこと言ったら OpenBSD のバッファオーバーフローを防ぐ仕組みや
libsafe だって厳密に言えばオーバーヘッドがあるわけで。
現に OpenBSD はベンチマークとかの結果は結構遅いじゃない。
実用的なレベルでパフォーマンスが落ちるのは本質的な問題じゃないし、
憶測で「圧倒的に」なんて言うのなら >>1 と同じようにソースや根拠を出すべきでは。

37 ：
>>25
Linux だと PaX かね。
http://pageexec.virtualave.net/

38 ：
WinFX: An All-Managed API
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm
最高だね。WinFXはもはやWin32を使用しない。

39 ：

40 ：
どうしてもメルコと勘違いしてしまいます
何か良い方法はありますでしょうか

41 ：
>>36
> >>32
> libsafe は static リンクしてると使えない、っていう欠点があったはずじゃ？
> preload が上手く働かんかったような。詳細きぼんぬ。
libcをスタティックリンクするのは特別な事情があるときだけだろうな。
メンテナンス用のコマンドくらいだろ。
サーバ系のソフトウエアじゃそんなことしない。

42 ：
>>1
どこっちゃったの？

43 ：
理解できなくなったのでもう見てないんじゃないかとw

44 ：
そういや、以前からHPが開発していた、root権限に対しても
アクセス制御を実施して、メモリー管理も見直してバッファオーバフローや
root権限奪取タイプの攻撃に対して強化したLinuxソースがもうじき
マージされるとか聞いたが。
Fedora Core 2ではその成果を取り込むらしいと言うのを、今月の
LinuxMagazineの記事で読んだ覚えがある。SELinuxだったかな？
ソースは雑誌が今手元にないので判らんが。
あと、Miracleが似たような事を売りにしたHizardとかいう製品を
売りに出していただろう。あれなんかもどうなんだろうね？

45 ：
Linux自体可変長バッファの扱いがへったくそなCで書かれてるし
その上のアプリもまだまだCが多いから
土台も家屋共に危険な環境だよな。

46 ：
GW前にMS04-011への対応を――経産省、総務省らが連名で呼びかけ
http://www.itmedia.co.jp/enterprise/0404/26/epn05.html
＞「..Windowsシリーズ以外のOSが導入されたコンピュータも攻撃対象となる可能性」があるとも述べられている。
＞事実、CiscoSystemsのIOS に存在するSNMPの脆弱性を狙ったExploitコードが公開されている。
＞したがって、非Windows系のシステムにおいても十分な警戒が必要だろう。

47 ：
Exec-shieldマンセー

48 ：
>>45
何で書かれていたら満足？

49 ：
VM上で動くアプリが標準になることなんてこの先5年はあり得ないだろパフォーマンス的に。
そうこうしているうちにD言語が流行るヨカン。
こちらは言語レベルで可変長配列サポートされるしｳﾏｰ
つかさー.netってVM上で動くことによるセーフ以外に何かいいことあるの？
Javaみたいに複数のプラットホームでVMが実装されてるならまだわかるんだけどさ。
Monoもｶｽだしどうしようもないな。
プログラマの無能さのツケをユーザに回そうってわけか。

50 ：
スレ主をかばうわけではないが、C言語という言語が古い言語なので、それを標準とするLinuxを疑問視する声は確かにある。
C++も使えるといっても、カーネルからデバイスドライバからアプリケーションまでほとんどC言語で作ってある。
C言語はオブジェクト指向という難しい考え方がないから勉強していないプログラマーにとっては楽だけどね。
私は勉強していないプログラマーなのでC言語でも問題ないと思うがユーザーからしてみるとケチつけたくなる気持ちはわかるよ。
C言語は確保していないメモリーのアクセスができるから問題なのはわかるんだが、BASICからCに移るときにそれを問題視する人はあまりいなかったと思う。
むしろ欠点より高速に動作できるという利点に解釈できるし。
パソコンが高速化した今、確保しているメモリのアクセスかどうかチェックする処理を言語上に取り入れても実用的な速度で動くだろう。
スレ主が言っていることは本当に問題と言えば問題だ。
個人的には何も困っていることないし問題じゃないけどね。

51 ：
FreeBSD4.8R入れて以来SAも一切無視してきてnaturalな状態で使い続けている漏れにとっては
ｾｷｭﾘﾃｨ関連のｽﾚは耳に痛いな。まぁ2ちゃん閲覧専用マシンだからどうでもいいんだが。

52 ：
>>21 で使っているgetline関数って、どのライブラリで提供されてるの？
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/getline.3.html
に解説されているものとは違うようだし…

53 ：
http://www.google.co.jp/search?q=getline+C%2B%2B&ie=UTF-8&oe=UTF-8&hl=ja&lr=

54 ：
細かくセグメント変えるぐらいのことはしてくんろだな。
細工もなにもせずに、カーネル空間からユーザ空間へ
writeできるのやっぱり糞だ。

55 ：
バッファオーバーフローは対策されたCPUがそのうち出てくるから
問題なくなるんでないかい？(そもそも気を付ければ済むことだし。)
http://www.itmedia.co.jp/news/articles/0405/18/news035.html
シンボリックリンクって便利だけど危険だね。
http://www.ipa.go.jp/security/awareness/vendor/programming/b07.html

56 ：
ここってマイクロソフト主催？

57 ：
Linuxでもそのうち対応してくんじゃないかという期待、だとおもうが。

58 ：
バカオーバフローの悪夢は覚めることがない。

59 ：
釣り掘と化したか

60 ：
340 名前：login:Penguin[] 投稿日：04/05/20 12:12 ID:XlJ3ta+B
オープンソース・コード管理アプリ「CVS」と「Subversion」に脆弱性
ttp://japan.cnet.com/news/sec/story/0,2000050480,20067763,00.htm
341 名前：login:Penguin[sage] 投稿日：04/05/20 15:06 ID:xVYeu6pD
C言語なんて使うからいつまでたってもセキュリティーホールが見つかるんだよ。

61 ：
CをやめてSecure C とでもいうような言語をきちんと決めて、
そういうので描き直したらいいのにね。いちおう大半はそっくり
コンバージョンできるような仕様にして。
本当は、OSはオブジェクト指向で記述すれば、うんとぴったり
来るはずのものだけど、普通はオブジェクト指向を支援するための
昨日がOSを利用してたりするので、卵と鶏になってしまいかねないから、
うんと軽いオブジェクト指向言語仕様にするんだろね。

62 ：
Javaで書き直せば問題なし
C→Javaのトランスレートって簡単らしいから
誰かやってくれないか

63 ：
Dで書き直せば問題なし
C→Dのトランスレートって簡単らしいから(ソース無し)
誰かやってくれないか

64 ：
D言語って誰か使ってるの？
いや、別に嫌味で言ってる訳じゃなくて…

65 ：
一部の信者がコピペしまくってウザいだけで
実際はほとんど使われてない
だいたい言語仕様もライブラリも未完成だし
それにC/C++を改善したって程度だから
わざわざ使ってくれる人はそうはいない

66 ：
>>61
Plan9にAlefって言語があったけどな。
concurrent and secure C with classesといった位置付けだったけど
ポータビリティーに難有りだかなんだかで死滅してしまったが。

67 ：
>>66
メンテナンスする手が足りないって話じゃなかった? 残念。eiffel も chill
も瀕死だし、言語の改良というのはテクノロジと違う部分が難しいみたいだな。

68 ：
データ領域を実行出来ないkernelにした時、
GNU Common Lisp(旧Kyoto Common Lisp)はどうなるのよ?
抜け道用意されているわけ?

69 ：
GCL 知らないんだけど、
WS の CPU って昔から NXbit みたいな機能あったよね?

70 ：
コンピュータ言語のセキュリティーを語るなら、もう少しマシン語とか
コンピュータアーキテクチャとかOSとかの勉強をしてからにしなよ。
このスレでは言語が提供する機能とアーキテクチャが提供する機能と
OSが提供する機能の区別が全くついてない香具師ばっかりじゃん。

71 ：
俺の上にいる恥ずかしいやつを何とかしてくれ．

72 ：
マシン語と言ってる時点でドシロウト

73 ：
Linuxでは無理

74 ：
そこでSEですよ、と敢えてってみる。

75 ：
>>1
そんなJavaもどきとネイティブアプリ比べる時点で鼻くそでしょう。

76 ：
　　（＾ω＾）⊃　ｱｳﾄ!!!
　　（⊃　）
　／　　　ヽ
　
⊂（　＾ω＾）⊃　ｾｰﾌ!!!
　　（　　　）
　／　　　ヽ
　　（　＾ω＾）　ヨヨイの!!
　 （⊃⊂　）
　／　　　ヽ
　
　　　　　 ／⌒ヽ
　　 　 　（＾ω＾　）　ﾌﾞｰﾝ　　　　　
　　　　／|　　　 ﾍ　　　　　 　
　　／／（　　 (＼＼
⊂／　 ( < ω　> )＼⊃
　 　　 ∠」　　└-ヽ　
　
　＿[警]　
　　(　 ) (^ω^ )
　　(　 )Ｖノ ）
　　 | |　　|

77 ：
>>1
そんなJavaもどきとネイティブアプリ比べる時点で鼻くそでしょう。

78 ：
データーとコードの領域を完全分離しようとすると、
ローダーが困る。

79 ：
アセンブラについて
http://asm.sourceforge.net/

80 ：
>>66
地下鉄の中で「アレフ入手してやってみたいんですが」といったら周りの
人間が引いた。

81 ：
とりあえず、ローカル変数として読み込み用の
バッファをつくらんようにすることかな。
構造体でも用意してmallocでやるようにするだけでも、
少なくともコードの実行は防げるだろうと。

82 ：
つ[ヒープオーバーフロー]

83 ：
そもそもCの精神は、天才ハカーにとって自由度の高い環境を
実現することであって、馬鹿の存在を想定していない。
躾が出来てない馬鹿は、C以前から存在していた
Pascalの統制を受けるべきだったんだよ。
ところが馬鹿にもCが普及してしまい、
馬鹿がPascalのエラーチェックうざいとか言い出す始末。
ベル研の人たちも、世の中にあまりに馬鹿が多い現実に
ようやく気付いたようで、Limboなんて言語作ってるし
Cは汎用プログラミング言語としては終わったと見ていいだろう。

84 ：
カーネル以外はRubyで組めば全て解決

85 ：
バッファオーバーフローの被害にあった人間なんていないだろ。
FUDだよ。
馬鹿ばっかりだな。ほんまに。

86 ：
バーカ↓

87 ：
DMD1.0が出たらLinuxをCからDへ書き直してもいいと思う。

88 ：
>>87
応援してるぞ。

89 ：
NXビットにLinuxが対応するのはまだですか？

90 ：
このスレの誰かがDだか何かで安全なリナックスを作って、公開しれ
そしたらおれがDLして使ってみてやるわ

91 ：
>>89
FC2やRHEL update3から対応だから一年以上前から対応してるよ。
オープンソースでも実装されるNX機能 - Linux kernel 2.6で利用
http://pcweb.mycom.co.jp/news/2004/06/07/009.html

92 ：
NX機能対応のCPUで無いと動かないのは、見落としやすいポイントですね。
＃要求仕様書にNXに対応したx86_64を搭載した．．．。とか書かれると、
＃コストが上がっちゃうなぁ。

93 ：
>>1
>Windowsは基本APIが.NET(WinFX)になって、
結局ならなかったね。
>OSもユーザアプリもバッファオーバーフローの
>悪夢から解放されますよ。
元の構想でもOSはC/C++だろ。ただAPIが.NETだというだけの話で。
>Linuxはどうですか？
いざそのせいでセキュリティーで抜かれたら、GCCのmudflapで実行時チェックを入れるだけ。
MSも本気でWin32APIを捨てるつもりなら、危険なIEとIISを.NETで造り直せばいいのにね。
とりあえず、それが実行されるまではC/C++も実用言語ということで。

94 ：
>>92
つexec-shield

95 ：
バッファ5ローの悪夢

96 ：
age?

97 ：
>>92
間違っています。
以上。
はい、次。

98 ：
age
えろい人たち現状でバトル再会してくれ

99 ：
バッファローがどうしましたか？

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
Linuxを売りにしてる会社について
Linux使いが使っているソフトと満足度
FVWM スレッド
Canna すれ 2頁目【かんな】