アカウント名:
パスワード:
「スタックは上のアドレスから使われる」のが諸悪の根源。下から使ってりゃオーバーフローしても被害はその関数の自動変数で収まる。
スタックがどちらに成長するかは処理系(とアーキテクチャ)依存です。とあるフリーのOSのライブラリを読んでるときに「MIPSでは下から上に成長するよ!」と書いてありました。上から下に向って成長しなければならない必然性はもはやありません。でも、いざ切り替えるとなると、いろいろうまく動かなくなるところがでてきそうですね。
でも、切り替えたところでどのくらいメリットがあるでしょうか? overflowの攻撃を防ぐだけなら実質address space layout randomizationだけで100%防げているような感覚はあります。昨今バッファオーバーフローで攻撃が成立するのは明示的にaddress space layout randomizationをオフにしたプロセスだけではないでしょうか。
配列は上から下につかんだからしょうがねーべよ。
言語仕様でそこまで規定していましたっけ?単に昔のプロセッサはpush/popの方向が一種類しかなかったための実装上の問題と思ってましたが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
分岐とデータのスタックを分離していないこと (スコア:1, 興味深い)
auto変数の配列を(リターンアドレス等に使う)メインのスタックではなく、別のスタックに置けば
かなりの改善を得られると思うんです。
別のスタックに対する操作はコンパイラが生成したコードでやるわけですから透過的に行えるし、
そのオーバーヘッドは、いちいちヒープを使うよりも遥かに少なくそしてメモリリークのバグをやらかしにくい。
まぁリターンアドレスを細工されることは防げても、他のデータにはみ出して上書きして特権的なフラグを操作する・・・なんてことには対処できませんが。
Re:分岐とデータのスタックを分離していないこと (スコア:2, すばらしい洞察)
「スタックは上のアドレスから使われる」のが諸悪の根源。
下から使ってりゃオーバーフローしても被害はその関数の自動変数で収まる。
Re:分岐とデータのスタックを分離していないこと (スコア:3, 参考になる)
スタックがどちらに成長するかは処理系(とアーキテクチャ)依存です。とあるフリーのOSのライブラリを読んでるときに「MIPSでは下から上に成長するよ!」と書いてありました。上から下に向って成長しなければならない必然性はもはやありません。
でも、いざ切り替えるとなると、いろいろうまく動かなくなるところがでてきそうですね。
でも、切り替えたところでどのくらいメリットがあるでしょうか? overflowの攻撃を防ぐだけなら実質address space layout randomizationだけで100%防げているような感覚はあります。昨今バッファオーバーフローで攻撃が成立するのは明示的にaddress space layout randomizationをオフにしたプロセスだけではないでしょうか。
Re: (スコア:0)
配列は上から下につかんだからしょうがねーべよ。
Re: (スコア:0)
Re: (スコア:0)
コードとスタックの領域を別々に確保できたわけじゃないので、コードが下から使われる以上、スタックは上からというのが必然だったのじゃよ。
Re: (スコア:0)
言語仕様でそこまで規定していましたっけ?
単に昔のプロセッサはpush/popの方向が一種類しかなかったための実装上の問題と思ってましたが。
Re: (スコア:0)
バッファ・オーバーフロー攻撃を防ぐ“万能薬”はあるか? [nikkeibp.co.jp]