Red Hat Enterprise Linux 3、Update 3でExec-ShieldとNXをサポート

yosshy 曰く、 "Red Hat 社のプレスリリースおよび ITmedia の記事によると、Red Hat Enterprise Linux 3 の最新アップデートに、Exec-shield とPIEのサポートがが盛り込まれ、NX (no execute)のサポートが IA-64からx86, AMD64, EM64Tへ拡大された。これにより、商用 Linux の世界のセキュリティが改善される事が期待されます。"

NX-bit 有効で問題のあるアプリケーション

[Mc.N (3705)]

Cliffのリストフィルタ：2004年7月7日～7月14日 [linux.com]で紹介されていたNX-bit を有効にすると問題のありそうなアプリケーション [iu.edu]について解決出来ているのか興味があります。Wine は置いておくとしても X や Java は解決した状態で出荷されないと、困るユーザーがいるのではないかと。

--
Mc.N

これでようやく、

[Anonymous Coward]

stack-protector 付き GCC [ibm.com] とさよならできるかしら。

# NX 対応システムに入れ替えるまでは無理か(涙)。

燃料投下

[Anonymous Coward]

IBMのはNXな領域に制御を移さないのが目的だから多層防御という観点からは有効のほうがいい

Re:これでようやく、

[Anonymous Coward]

GCCのSSP拡張とかはそのgccを使ってコンパイルした
アプリケーションにしか有効ではありません。

その点、OSやCPU側での対処とは範囲が異なります。
(こちらはSSP拡張ではないGCCや、非GCCでコンパイル
されたバイナリに対しても有効に働く)

Transmetaは？

[Anonymous Coward]

Sharpが新モデル [impress.co.jp]とか発表してますが、EfficeonのNX機能は有効にならんのですかね？

# プレスがslashdotted(?)でみれない・・

Re:Transmetaは？

[SHNSK (10099)]

>また、Windows XP Service Pack2で導入されたデータ実行保護機能に対応。バッファオーバーランを悪用した未知のウイルスからPCを保護できるとしている。

とあるので，有効になっていそうですね．

Re:Transmetaは？

[M-FalconSky (8868)]

というか、Efficeon*で*有効になるかどうかですよね。

1.CPUの型から有効/無効をチェックしている
    -> Efficeonは判定でdisableになってしまう?
2.Flagの有無で有効/無効をチェックしている
    -> 有効になりそう

たぶん2なので有効でしょうが、微妙ですね...

--
M-FalconSky (暑いか寒い)

というか

[Anonymous Coward]

こんなもん、丁寧にプログラムを書けば不要でないのか？
教えてえろい人

Re:というか

[Anonymous Coward]

もちろん不要

でも実際に丁寧に書けるなんて信じてる奴がいる間は絶対必要

Re:というか

[Anonymous Coward]

なんかおまいらバッファーオーバーフローは仕方ないとでも言いたげだな。
あんなのプログラマとしては最低級の手抜きの結果だぜ。
ま、この業界もいつのまにかコードを書けないどころか読めないヴァカが
いっちょまえのエンジニアづらしてるようになっちまったもんな。
壊れてるところを修理もできないんじゃダメだね。ソースをいじれないような
システムで安穏としてるのもダメだね。

Re:というか

[swd_rgv (4751)]

その通りですよ。その通り。

だが、1つの方法で安心するのではなく、
- パケットフィルタ
- サービスを提供するプログラム自身のセキュリティ設計
- ユーザへのセキュリティポリシー
など複数の方法でセキュリティを確保しておくのは良いことだと思います。
NXは2番目がまずかったときの保険に過ぎないわけで。
日頃から癖つけて書くのは当たり前。

# でも出来てない人いるんだよなぁ。
# 自分より10年も経験してる人。何やってきてたんだろ?
# 指摘するのもある意味はずかしい。

Re:というか

[Anonymous Coward]

セキュリティ設計どころか、バッファの確保はプログラミングの基本中の基本ではないのか？
メモリコアの時代から境界破壊は注意すべきポイントだったんだから。

ところでこのNXが動作している場合、自分自身で復帰アドレスを書きかえる類のプログラムは動かなくなるの？

Re:というか

[WindKnight (1253)]

復帰アドレスの先が実行可能になっていれば、動くでしょうね。

だから、攻撃者に都合の良い処理へダイレクトに繋ぐという方法はあり得ます。

Re:というか

[Anonymous Coward]

スタックにコードを積んで実行する類のプログラムはアウトですね。
MS も昔はそういう製品を出荷してたらしいです。

Re:というか

[nekopon (1483)]

スタックにコードを積んで実行する類のプログラムはアウトですね。
MS も昔はそういう製品を出荷してたらしいです。

いくつかの UNIX の sigreturn もだす。この関係で *BSD では NX の導入が遅れたとかなんとかいう話が(もとむフォロー)。

Re:というか

[Anonymous Coward]

自分の書いたコードで使うライブラリがバッファオーバーフローしてると・・・・
そんな問題があるような、最低級の手抜きをするような輩の作ったライブラリなんて使う方が悪いですか。そうですか。

＃転ばぬ先の杖というか、問題が起きても大丈夫な仕組みを作ろうというものだと思っていたが＞NX

Re:というか

[Anonymous Coward]

ま、ライブラリのソースくらい確認しようぜ。
なんつって、どうせ売りもんのライブラリだったりして、ソースなんかないんだよな。そんなもん捨てちまえ。

Re:というか

[Anonymous Coward]

既製品のライブラリを使うのは手を抜くためなのだが？

Re:というか

[Anonymous Coward]

どんなに気をつけていてもミスは起こります。現実に起こりうる事象に対して、前もって対策しておくことは悪いことではないと思います。
どんなに運転に自信があってもシートベルトは忘れずに。
＃ネタにマジレス?

Re:というか

[Anonymous Coward]

気を付けてもダメだった時の保険なのさ。

Re:というか

[Anonymous Coward]

ウィルス対策って知ってます？

Re:というか

[Anonymous Coward]

OSやサービスなど、コンピュータ上で動作するすべてのプログラムが、自分が作成した信頼のできる丁寧に書かれたプログラムである、という人には不要なものだと思います。

Re:というか

[Anonymous Coward]

その通り。丁寧に作ればNXなど無力である。 [nikkeibp.co.jp]

半分悪意をこめてます。

Re:というか

[Anonymous Coward]

djbに聞いてみな