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

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

Linuxはバッファオーバーフローの悪夢から解放されるか?

1 :login:Penguin:03/12/09 21:16 ID:NTmeoy9v
Windowsは基本APIが.NET(WinFX)になって、
少なくとも新APIと.NETを使っている限りは、
OSもユーザアプリもバッファオーバーフローの
悪夢から解放されますよ。
Linuxはどうですか?

2 :login:Penguin:03/12/09 21:18 ID:6arzfUBz
糞を食べます

3 :login:Penguin:03/12/09 21:19 ID:6arzfUBz
糞を食べます

4 :login:Penguin:03/12/09 21:19 ID:WuSGmZG7
>>1
とりあえず、書いている内容の根拠を教えて。
君が単なる無知なら削除依頼を出しておいてね。

5 :login:Penguin:03/12/09 21:24 ID:wYnM9vxF
>>1
IDがNT

6 :login:Penguin:03/12/09 21:35 ID:NTmeoy9v
おぉ。すげーぜNT。

>>4
根拠も何も、強力なメモリ管理機能のおかげで、
バッファあふれたくらいで不正なデータ領域に
コード書くことなんかできませんよ。

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

7 :4:03/12/09 21:51 ID:WuSGmZG7
>>6
君には難しすぎたか…

>強力なメモリ管理機能
「この根拠を示せ」と言っているんです。わかりますか?

わからんなら削除依頼出せよ。



あ、もしかして、
 「MSのプログラムにバグや設計ミスなどない」
 「宣伝広告まんせー」
って信仰しているタイプ?

8 :login:Penguin:03/12/09 21:57 ID:NTmeoy9v
>>7
出来るというのならそれを証明するコードをおねがいします。

9 :4=7:03/12/09 22:04 ID:WuSGmZG7
>>1 が単なる馬鹿だとわかったので、オレはしばらく放置orROMします。

10 :login:Penguin:03/12/09 22:20 ID:NTmeoy9v
>>9
さようなら。もうこなくていいから。

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

11 :login:Penguin:03/12/09 22:21 ID:iLZEPRi/
>>10
バッファオーバーフローに限って言えば、パッチ出てるじゃん遥か前から。

12 :login:Penguin:03/12/09 22:25 ID:9WKnO9Mt
頭の可哀想な奴が居る

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

14 :login:Penguin:03/12/09 22:31 ID:krpe131M
先に「MSの.NETがどーたらだからメモリ管理があーだこーだ」のソースを出さないと誰も何を言って良いかわからん。
聞くなら先に自分の根拠。
情報のソース(どこかのニュースwebにリンクを張るとか)を提示してくれ。
話はそれからだ。

このスレがクソで終わるか名スレになるかはディスプレイの前の>>1次第だ。

じゃ、期待してないががんばれ。

15 :login:Penguin:03/12/09 22:33 ID:a28PAUx4
XPSP2でメモリ保護機能が付く記事がMSにあったが.NETとは関係ないぞ。

16 :login:Penguin:03/12/09 22:36 ID:1wZYu+r4
どうせ例外はくか、OSにクラッシュさせられるだけだろ?
最初からちゃんと動くプログラムかけよ。無能が。

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

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

19 :login:Penguin:03/12/09 22:44 ID:1wZYu+r4
はぁ?1億字を適切に処理しろよ?なんでプロセスが落とされる必要があるわけ?

20 :login:Penguin:03/12/09 22:45 ID:7Bx61/4O
>>18
デーモン側で制限出来るだろ。



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

22 :login:Penguin:03/12/09 23:10 ID:prQN2kg8
専門的なことを書いても >1 には理解できない気がするのですが…
理解できなくても問題ないけど。

23 :login:Penguin:03/12/09 23:12 ID:Gx+JHFkW
ネタスレで真面目に議論する

削除されない

>>1の空age天国

24 :login:Penguin:03/12/09 23:16 ID:prQN2kg8
>>23
オレは >1 はマジだと思う。無知で傲慢なだけ。

スレ立てた人がアフォでも、まぐれで良スレになることも希にありますよ。

25 :login:Penguin:03/12/09 23:25 ID:eoRAxueA
>>17
> まぁでも折角i386系はDSとCS区別できるような構造になってるんだから、
> そろそろコード空間とデータ空間分けてもいいよな。

既にOpenBSDは実現していますが、何か?
ttp://www.openbsd.org/papers/pacsec03/j/

そもそもセグメント単位でしか実行の許可が与えられないのが
i386アーキテクチャのダメな所。
ページ単位で実行許可を制御できるsparcなどのほうが
よっぽど楽にコード空間とデータ空間の分離を行なえる。

26 :login:Penguin:03/12/09 23:33 ID:prQN2kg8
>>25
リンク先がいま一つだな。
ちゃんとしたリンクキボン。

27 :login:Penguin:03/12/10 00:01 ID:efQW1LTw
で、>>1 はやっぱりアレだったの?

28 :login:Penguin:03/12/10 00:07 ID:rfo6ztDS
誘導

☆Linux カーネルの仕組みを勉強するスレ☆
http://pc.2ch.net/test/read.cgi/linux/1002012247/

どうすりゃいいんだ!Linuxのセキュリティ
http://pc.2ch.net/test/read.cgi/linux/1060840105/

29 :login:Penguin:03/12/10 02:05 ID:nsBUvTaF
スタック上に配列を切らない。

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

31 :login:Penguin:03/12/10 07:51 ID:MAgVbAPa
>>21
バッファオーバーフローを防ぐしくみとしてはそれだな。

だが仮にバッファオーバーフローが起こったとしても
コード実行はされない安全策は>>17
既存のコードをすべて>>21に修正するなんてできないし。

>>25
OpenBSDすばらしい!
Linuxも2.6あたりで実現という話はないの?


32 :+++:03/12/10 08:49 ID:M5iyzbrJ
.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 :login:Penguin:03/12/10 09:16 ID:nsBUvTaF
>.NETはJavaVMのようなもんだから
スタックの使い方は違う。
オブジェクト自体をスタック上にも置けるのが.NET

34 :+++:03/12/10 09:22 ID:M5iyzbrJ
>>33
structの場合ね。しかし、それは些事だなあ。

35 :login:Penguin:03/12/10 12:48 ID:0USIQVp9
実際にIISとかが.netベースで書かれたら圧倒的にパフォーマンス落ちるだろうね
んで誰も使わなくなるだろうね。

36 :ヽ(´ー`)ノ:03/12/10 15:05 ID:JpXey00O
>>32
libsafe は static リンクしてると使えない、っていう欠点があったはずじゃ?
preload が上手く働かんかったような。詳細きぼんぬ。

OpenBSD の場合、>>32 で例示されてる物以外にもセキュリティを確保する仕組みが
色々あって、任意のコードが実行される可能性は極端に低いと思う。

>>35
そんなこと言ったら OpenBSD のバッファオーバーフローを防ぐ仕組みや
libsafe だって厳密に言えばオーバーヘッドがあるわけで。
現に OpenBSD はベンチマークとかの結果は結構遅いじゃない。

実用的なレベルでパフォーマンスが落ちるのは本質的な問題じゃないし、
憶測で「圧倒的に」なんて言うのなら >>1 と同じようにソースや根拠を出すべきでは。


37 :login:Penguin:03/12/11 12:58 ID:s8B68Yl7
>>25
Linux だと PaX かね。
http://pageexec.virtualave.net/


38 :login:Penguin:03/12/11 21:24 ID:em/UXWTt
WinFX: An All-Managed API
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm

最高だね。WinFXはもはやWin32を使用しない。

39 :login:Penguin:03/12/11 21:25 ID:em/UXWTt


40 :login:Penguin:03/12/12 15:19 ID:SAb1Ew0H
どうしてもメルコと勘違いしてしまいます
何か良い方法はありますでしょうか

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

42 :login:Penguin:04/04/27 19:38 ID:AAWjsDra
>>1
どこ逝っちゃったの?

43 :login:Penguin:04/04/28 02:56 ID:MRYZFIX4
理解できなくなったのでもう見てないんじゃないかとw

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

あと、Miracleが似たような事を売りにしたHizardとかいう製品を
売りに出していただろう。あれなんかもどうなんだろうね?


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

46 :login:Penguin:04/04/28 20:48 ID:3Wa0fukA
GW前にMS04-011への対応を――経産省、総務省らが連名で呼びかけ
http://www.itmedia.co.jp/enterprise/0404/26/epn05.html

>「..Windowsシリーズ以外のOSが導入されたコンピュータも攻撃対象となる可能性」があるとも述べられている。
>事実、CiscoSystemsのIOS に存在するSNMPの脆弱性を狙ったExploitコードが公開されている。
>したがって、非Windows系のシステムにおいても十分な警戒が必要だろう。

47 :login:Penguin:04/04/28 22:30 ID:eHWavgjl
Exec-shieldマンセー

48 :login:Penguin:04/04/29 15:51 ID:FcL9MHAK
>>45
何で書かれていたら満足?


49 :login:Penguin:04/04/29 20:19 ID:I1/R6fwh
VM上で動くアプリが標準になることなんてこの先5年はあり得ないだろパフォーマンス的に。
そうこうしているうちにD言語が流行るヨカン。
こちらは言語レベルで可変長配列サポートされるしウマー

つかさー.netってVM上で動くことによるセーフ以外に何かいいことあるの?
Javaみたいに複数のプラットホームでVMが実装されてるならまだわかるんだけどさ。
Monoもカスだしどうしようもないな。
プログラマの無能さのツケをユーザに回そうってわけか。

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


51 :login:Penguin:04/04/30 04:01 ID:vBF6yA34
FreeBSD4.8R入れて以来SAも一切無視してきてnaturalな状態で使い続けている漏れにとっては
セキュリティ関連のスレは耳に痛いな。まぁ2ちゃん閲覧専用マシンだからどうでもいいんだが。

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

53 :login:Penguin:04/04/30 16:47 ID:GAlS4J4e
http://www.google.co.jp/search?q=getline+C%2B%2B&ie=UTF-8&oe=UTF-8&hl=ja&lr=

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

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

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