アカウント名:
パスワード:
スタックにコードを積んで実行する類のプログラムはアウトですね。 MS も昔はそういう製品を出荷してたらしいです。
いくつかの UNIX の sigreturn もだす。この関係で *BSD では NX の導入が遅れたとかなんとかいう話が(もとむフォロー)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
というか (スコア:0)
教えてえろい人
Re:というか (スコア:1, 興味深い)
あんなのプログラマとしては最低級の手抜きの結果だぜ。
ま、この業界もいつのまにかコードを書けないどころか読めないヴァカが
いっちょまえのエンジニアづらしてるようになっちまったもんな。
壊れてるところを修理もできないんじゃダメだね。ソースをいじれないような
システムで安穏としてるのもダメだね。
Re:というか (スコア:2, 興味深い)
だが、1つの方法で安心するのではなく、
- パケットフィルタ
- サービスを提供するプログラム自身のセキュリティ設計
- ユーザへのセキュリティポリシー
など複数の方法でセキュリティを確保しておくのは良いことだと思います。
NXは2番目がまずかったときの保険に過ぎないわけで。
日頃から癖つけて書くのは当たり前。
# でも出来てない人いるんだよなぁ。
# 自分より10年も経験してる人。何やってきてたんだろ?
# 指摘するのもある意味はずかしい。
Re:というか (スコア:0)
メモリコアの時代から境界破壊は注意すべきポイントだったんだから。
ところでこのNXが動作している場合、自分自身で復帰アドレスを書きかえる類のプログラムは動かなくなるの?
Re:というか (スコア:1)
だから、攻撃者に都合の良い処理へダイレクトに繋ぐという方法はあり得ます。
Re:というか (スコア:0)
MS も昔はそういう製品を出荷してたらしいです。
Re:というか (スコア:1)
いくつかの UNIX の sigreturn もだす。この関係で *BSD では NX の導入が遅れたとかなんとかいう話が(もとむフォロー)。
Re:というか (スコア:0)
そんな問題があるような、最低級の手抜きをするような輩の作ったライブラリなんて使う方が悪いですか。そうですか。
#転ばぬ先の杖というか、問題が起きても大丈夫な仕組みを作ろうというものだと思っていたが>NX
Re:というか (スコア:0)
なんつって、どうせ売りもんのライブラリだったりして、ソースなんかないんだよな。そんなもん捨てちまえ。
Re:というか (スコア:0)
Re:というか (スコア:0)
どんなに運転に自信があってもシートベルトは忘れずに。
#ネタにマジレス?