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

1 ：login:Penguin：03/12/09 21:16 ID:NTmeoy9v.net

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

2 ：login:Penguin：03/12/09 21:18 ID:6arzfUBz.net

糞を食べます

3 ：login:Penguin：03/12/09 21:19 ID:6arzfUBz.net

糞を食べます

4 ：login:Penguin：03/12/09 21:19 ID:WuSGmZG7.net

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

5 ：login:Penguin：03/12/09 21:24 ID:wYnM9vxF.net

>>1
IDがNT

6 ：login:Penguin：03/12/09 21:35 ID:NTmeoy9v.net

おぉ。すげーぜNT。

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

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

7 ：4：03/12/09 21:51 ID:WuSGmZG7.net

>>6
君には難しすぎたか…

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

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



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

8 ：login:Penguin：03/12/09 21:57 ID:NTmeoy9v.net

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

9 ：4=7：03/12/09 22:04 ID:WuSGmZG7.net

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

10 ：login:Penguin：03/12/09 22:20 ID:NTmeoy9v.net

>>9
さようなら。もうこなくていいから。

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

11 ：login:Penguin：03/12/09 22:21 ID:iLZEPRi/.net

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

12 ：login:Penguin：03/12/09 22:25 ID:9WKnO9Mt.net

頭の可哀想な奴が居る

13 ：login:Penguin：03/12/09 22:29 ID:O5EhARHt.net

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

14 ：login:Penguin：03/12/09 22:31 ID:krpe131M.net

先に「MSの.NETがどーたらだからメモリ管理があーだこーだ」のソースを出さないと誰も何を言って良いかわからん。
聞くなら先に自分の根拠。
情報のソース（どこかのニュースwebにリンクを張るとか）を提示してくれ。
話はそれからだ。

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

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

15 ：login:Penguin：03/12/09 22:33 ID:a28PAUx4.net

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

16 ：login:Penguin：03/12/09 22:36 ID:1wZYu+r4.net

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

17 ：login:Penguin：03/12/09 22:39 ID:xTy57Tdq.net

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

18 ：login:Penguin：03/12/09 22:41 ID:O5EhARHt.net

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

19 ：login:Penguin：03/12/09 22:44 ID:1wZYu+r4.net

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

20 ：login:Penguin：03/12/09 22:45 ID:7Bx61/4O.net

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

21 ：login:Penguin：03/12/09 22:47 ID:O5EhARHt.net

>>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.net

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

23 ：login:Penguin：03/12/09 23:12 ID:Gx+JHFkW.net

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

24 ：login:Penguin：03/12/09 23:16 ID:prQN2kg8.net

>>23
オレは >1 はマジだと思う。無知で傲慢なだけ。

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

25 ：login:Penguin：03/12/09 23:25 ID:eoRAxueA.net

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

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

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

26 ：login:Penguin：03/12/09 23:33 ID:prQN2kg8.net

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

27 ：login:Penguin：03/12/10 00:01 ID:efQW1LTw.net

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

28 ：login:Penguin：03/12/10 00:07 ID:rfo6ztDS.net

誘導

☆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.net

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

30 ：login:Penguin：03/12/10 03:56 ID:dDzAanXr.net

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

31 ：login:Penguin：03/12/10 07:51 ID:MAgVbAPa.net

>>21
バッファオーバーフローを防ぐしくみとしてはそれだな。

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

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

32 ：＋＋＋：03/12/10 08:49 ID:M5iyzbrJ.net

.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

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

34 ：＋＋＋：03/12/10 09:22 ID:M5iyzbrJ.net

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

35 ：login:Penguin：03/12/10 12:48 ID:0USIQVp9.net

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

36 ：ヽ(´ー`)ノ：03/12/10 15:05 ID:JpXey00O.net

>>32
libsafe は static リンクしてると使えない、っていう欠点があったはずじゃ？
preload が上手く働かんかったような。詳細きぼんぬ。

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

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

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

37 ：login:Penguin：03/12/11 12:58 ID:s8B68Yl7.net

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

38 ：login:Penguin：03/12/11 21:24 ID:em/UXWTt.net

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.net

40 ：login:Penguin：03/12/12 15:19 ID:SAb1Ew0H.net

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

41 ：login:Penguin：04/02/22 00:12 ID:wtxifEQr.net

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

42 ：login:Penguin：04/04/27 19:38 ID:AAWjsDra.net

>>1
どこ逝っちゃったの？

43 ：login:Penguin：04/04/28 02:56 ID:MRYZFIX4.net

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

44 ：login:Penguin：04/04/28 12:27 ID:O0WJ5Nsf.net

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

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

45 ：login:Penguin：04/04/28 19:53 ID:omtPLdDP.net

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

46 ：login:Penguin：04/04/28 20:48 ID:3Wa0fukA.net

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.net

Exec-shieldマンセー

48 ：login:Penguin：04/04/29 15:51 ID:FcL9MHAK.net

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

49 ：login:Penguin：04/04/29 20:19 ID:I1/R6fwh.net

VM上で動くアプリが標準になることなんてこの先5年はあり得ないだろパフォーマンス的に。
そうこうしているうちにD言語が流行るヨカン。
こちらは言語レベルで可変長配列サポートされるしｳﾏｰ

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

50 ：login:Penguin：04/04/29 21:41 ID:Ue6vZX6f.net

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

51 ：login:Penguin：04/04/30 04:01 ID:vBF6yA34.net

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

52 ：login:Penguin：04/04/30 16:31 ID:XGHUzjSv.net

>>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.net

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

54 ：LOGON：04/05/18 01:38 ID:jisIMQba.net

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

55 ：login:Penguin：04/05/18 16:22 ID:P/XZSN8X.net

バッファオーバーフローは対策されたCPUがそのうち出てくるから
問題なくなるんでないかい？(そもそも気を付ければ済むことだし。)
http://www.itmedia.co.jp/news/articles/0405/18/news035.html

シンボリックリンクって便利だけど危険だね。
http://www.ipa.go.jp/security/awareness/vendor/programming/b07.html

56 ：login:Penguin：04/05/18 20:12 ID:yut90iiQ.net

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

57 ：login:Penguin：04/05/18 20:19 ID:Nf8KG/OE.net

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

58 ：login:Penguin：04/05/18 21:03 ID:O0vkrs+7.net

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

59 ：login:Penguin：04/05/19 02:34 ID:u43xRlSn.net

釣り掘と化したか

60 ：login:Penguin：04/05/20 20:53 ID:DxrMaQMN.net

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 ：login:Penguin：04/08/12 02:25 ID:U1YuMU/Y.net

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

62 ：login:Penguin：04/08/14 18:16 ID:917sVZC6.net

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

63 ：login:Penguin：04/08/17 20:54 ID:ROSIbulh.net

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

64 ：login:Penguin：04/08/19 03:10 ID:cUXKGxoo.net

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

65 ：login:Penguin：04/08/19 07:17 ID:tNsslStd.net

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

66 ：login:Penguin：04/08/19 15:54 ID:v+h1kvng.net

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

67 ：login:Penguin：04/08/22 17:56 ID:f2pM98Bv.net

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

68 ：login:Penguin：04/08/23 13:54 ID:DBsbl97M.net

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

69 ：login:Penguin：04/08/24 00:29 ID:fMrgGK7G.net

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

70 ：login:Penguin：04/08/25 13:35 ID:Xn0DRMTe.net

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

71 ：login:Penguin：04/08/25 13:39 ID:DANkXVR6.net

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

72 ：login:Penguin：04/10/13 01:26:39 ID:bQQvNlBB.net

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

73 ：login:Penguin：2005/04/10(日) 04:18:10 ID:lU86+FvC.net

Linuxでは無理

74 ：login:Penguin：2005/04/10(日) 06:35:37 ID:593PUz/B.net

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

75 ：login:Penguin：2005/04/10(日) 08:06:32 ID:Ji/T7Rx7.net

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

76 ：login:Penguin：2005/04/10(日) 22:18:12 ID:o98Om+aU.net

　　（＾ω＾）⊃　ｱｳﾄ!!!
　　（⊃　）
　／　　　ヽ
　
⊂（　＾ω＾）⊃　ｾｰﾌ!!!
　　（　　　）
　／　　　ヽ

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

77 ：login:Penguin：2005/04/10(日) 22:42:55 ID:qmeVoo2g.net

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

78 ：login:Penguin：2005/05/08(日) 02:47:40 ID:9L6Mz2ay.net

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

79 ：どうでもいいかもしれんが：2005/05/09(月) 14:16:39 ID:lhJoEKU9.net

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

80 ：login:Penguin：2005/06/11(土) 19:44:11 ID:Uk0g4NPh.net

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

81 ：login:Poelina：2005/06/16(木) 19:48:10 ID:sQgmF1vt.net

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

82 ：login:Penguin：2005/06/16(木) 21:34:45 ID:/YpmM6Ls.net

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

83 ：login:Penguin：2005/06/16(木) 21:45:48 ID:hNgFnzea.net

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

84 ：login:Penguin：2005/06/16(木) 21:50:59 ID:bI1d/37c.net

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

85 ：login:Penguin：2005/06/17(金) 16:10:43 ID:r2abT8Mn.net

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

86 ：login:Penguin：2005/06/19(日) 00:56:43 ID:rQnM9ppS.net

バーカ↓

87 ：login:Penguin：2005/06/28(火) 21:02:04 ID:n+gd5yH6.net

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

88 ：login:Penguin：2005/06/28(火) 23:39:47 ID:9WCLhZAD.net

>>87
応援してるぞ。

89 ：login:Penguin：2005/10/30(日) 11:24:06 ID:Yru/v9DX.net

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

90 ：login:Penguin：2005/10/30(日) 12:23:18 ID:h05oYvYN.net

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

91 ：login:Penguin：2005/10/31(月) 22:33:51 ID:JKjqGt5M.net

>>89

FC2やRHEL update3から対応だから一年以上前から対応してるよ。

オープンソースでも実装されるNX機能 - Linux kernel 2.6で利用
http://pcweb.mycom.co.jp/news/2004/06/07/009.html

92 ：login:Penguin：2005/11/01(火) 08:16:29 ID:F8cZVhxQ.net

NX機能対応のCPUで無いと動かないのは、見落としやすいポイントですね。

＃要求仕様書にNXに対応したx86_64を搭載した．．．。とか書かれると、
＃コストが上がっちゃうなぁ。

93 ：login:Penguin：2005/11/01(火) 17:43:52 ID:oV/NvhoQ.net

>>1
>Windowsは基本APIが.NET(WinFX)になって、
結局ならなかったね。
>OSもユーザアプリもバッファオーバーフローの
>悪夢から解放されますよ。
元の構想でもOSはC/C++だろ。ただAPIが.NETだというだけの話で。
>Linuxはどうですか？
いざそのせいでセキュリティーで抜かれたら、GCCのmudflapで実行時チェックを入れるだけ。

MSも本気でWin32APIを捨てるつもりなら、危険なIEとIISを.NETで造り直せばいいのにね。
とりあえず、それが実行されるまではC/C++も実用言語ということで。

94 ：login:Penguin：2005/11/01(火) 23:49:29 ID:9zntAz47.net

>>92
つexec-shield

95 ：login:Penguin：2005/11/12(土) 19:39:36 ID:l90vayqM.net

バッファ5ローの悪夢

96 ：login:Penguin：2007/01/11(木) 03:41:49 ID:koHalbyh.net

age?

97 ：login:Penguin：2008/04/23(水) 20:03:49 ID:ik0CRtGR.net

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

98 ：login:Penguin：2008/07/16(水) 03:32:29 ID:J4HSdWQX.net

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

99 ：login:Penguin：2008/07/16(水) 03:44:05 ID:2XS3TY3h.net

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

100 ：アジェグ４倍 ◆4xAJeG.COM ：2008/07/16(水) 09:50:31 ID:IkaQsH1g.net

あれから４年半経ったわけだが、.NETはどれだけ広まったかねぇ？

101 ：login:Penguin：2008/07/16(水) 14:17:33 ID:P4Kyofsp.net

バッファーオーバーフローは、
スタック領域にコードを書いて実行させる。
そこにPC（プログラムカウント）を持っていくには、
スタックに常に保存されれている上位ルーチンへのリターンアドレス
をバッファーオーバーフローで書き換えてしまえばいい。
コード領域もデータ領域もいじらないからメモリー管理では防げない。

102 ：login:Penguin：2008/07/16(水) 17:18:08 ID:jzn+GK87.net

WindowsもBSD＝Mac OSXも着々と進歩しているというのに
Linuxだけが時代に取り残されてしまっているよね。

103 ：login:Penguin：2008/07/16(水) 17:48:45 ID:WYsUaqKn.net

おーえすがどうこう出来る話ではありません

あしからず

104 ：login:Penguin：2008/07/16(水) 20:15:32 ID:J4HSdWQX.net

.netでバッファオーバーフローから解放されたとしても
投げられたエクセプションとかを無視してて
即終了しちゃうようなプログラムじゃだめだよね？
まあ、クラックされて乗っ取られるとかは起きなくなるのかな

結局はコーダーしだい？

105 ：マイク ◆yrBrqfF1Ew ：2008/07/19(土) 07:37:31 ID:1HNX+3ab.net

メモリ上のプログラムのセクションだっけ
それを実行禁止にすればヤバそうな事態の危険を減らせるんじゃね
実行必要のあるセクションだけ許可設定にしとけば

106 ：login:Penguin：2008/07/19(土) 11:46:26 ID:+Um9+A7s.net

Linuxのパーティションに重要なデータをおかないようにする事こそが
究極のセキュリティといえるだろう。

107 ：login:Penguin：2008/07/26(土) 09:45:50 ID:passfzsE.net

IA32のLinuxってコード＝データ＝スタックなん？
素人考えで、セレクタが独立してるんだからコード≠データ≠スタックにしてコード以外は実効権与えないようにすれば386でもスタックオーバーフローは防げるような気がするんだけど…

まさかリアルモード！？

108 ：login:Penguin：2008/07/26(土) 10:31:03 ID:passfzsE.net

/スタックオーバーフロー/バッファオーバーフロー/

スタックオーバーフローは別物じゃんかYO!

109 ：login:Penguin：2008/08/17(日) 17:22:00 ID:+nqHqx6C.net

バッファは多くは実行時にスタックに取る。
それが一番お手軽。
メモリープールに取るのと違って解放が要らないからな。

110 ：login:Penguin：2008/08/17(日) 17:33:50 ID:+nqHqx6C.net

実行権限を与えるってファイルの権限ではないんだから、
セグメントにそんな権限与えられたっけ？
PC（プログラムカウンター）にはどんなアドレスでも入れられるだろ。
たとえば０番地を入れて０番地から実行できる。
たいてい例外起こしてそのプロセスはアボートされるが、不正命令でなくて
ときたまコードなら実行しちゃうがな。
暴走ってやつ。w

111 ：login:Penguin：2009/02/07(土) 20:35:30 ID:YFAKXxBb.net

いつから.NetでWindowsのサービスが動作してるのか？

112 ：login:Penguin：2009/06/10(水) 02:00:35 ID:tSVkUGH/.net

いいからしゃぶれ

113 ：login:Penguin：2012/05/26(土) 04:00:19.40 ID:WLs+PXye.net

力抜けよ

114 ：login:Penguin：2014/01/17(金) 12:07:51.98 ID:vq/z8FI2.net

初めてなんです