アカウント名:
パスワード:
どんなに素晴らしいセキュリティ対策を考案しても互換性が保てなければWindowsでは絵に描いた餅だし。EMETで設定できるSEHOPも本来は既存のアプリに未変更で適用できる対策として考案されたのに、CygwinやSkype等で不具合出まくりなのでDEPやASLRと大差ないアプリケーションごとのホワイトリストになってしまいましたとさ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
なぜコールスタックとデータスタックを分けない (スコア:0)
既存のCPUでも、Cコンパイラ側で分けること、できますよね。
なぜ、やらないのだろう。
何か、できない理由があるのだろうか。
Re: (スコア:1)
Re: (スコア:0)
どんなに素晴らしいセキュリティ対策を考案しても互換性が保てなければWindowsでは絵に描いた餅だし。
EMETで設定できるSEHOPも本来は既存のアプリに未変更で適用できる対策として考案されたのに、CygwinやSkype等で不具合出まくりなのでDEPやASLRと大差ないアプリケーションごとのホワイトリストになってしまいましたとさ。
Re:なぜコールスタックとデータスタックを分けない (スコア:0)
callerとcalleeが両方ともアプリケーションの中の関数なら、カスタムのcall規約を使うことが出来るハズですよ。
たとえば酷いコードの例として
void foo(char *a, char *b) {
char hoge[100] ;
sprintf(hoge, "%s and %s", a, b) ;
doSomething(hoge) ;
}
こんなのがあったとき、(sprintfを使うな!というのは、とりあえず、おいといて)
関数の引数aとbを(CPU管理の)スタックに積むのは良いが、auto変数のhoge配列を(CPU管理の)スタック上に持つのは危険だよね。
これをCPU管理ではないスタック上に確保すれば、かなりの危険を回避できると思うのです。
少なくとも、リターン先のアドレスを操作されることからは、逃れられる。
ヒープの代わりに(CPU管理ではない別の)スタックを使うのは、メモリ管理のオーバーヘッドを大幅に軽減するテクニックとして、使われることがありますが、それをCコンパイラが自動的にauto変数に対して適用すればいいと思うんですよ。