アカウント名:
パスワード:
ヒープをターゲットにした攻撃の可能性は残りますから注意は必要ですが、オーバーフローを起こしそうなコ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
コード実行の制限 (スコア:2, 参考になる)
ヒープをターゲットにした攻撃の可能性は残りますから注意は必要ですが、オーバーフローを起こしそうなコ
の
Re:コード実行の制限 (スコア:2, 参考になる)
> というのが面白いです。バッファオーバーフローに基づいた攻撃が
> ほとんど無効化されます。
これって大昔からあちこちで提案されているけど、signal trampolineとかの
メカニズムでスタックのコード実行が必要となるために、いつもお流れと
なっています。
今回、OpenBSDがスタック上でのコード実行を不可能としたいきさつが
気になりますね。
Re:コード実行の制限 (スコア:2, 参考になる)
シグナルトランポリンを libc などに置くというアイディアには、
スタックオーバーフロー対策に有効という利点もあるけど、
欠点も同様にあって(たとえば libc にトランポリンを置くとして、
libc のロードに失敗したときにどうしようもない、など)、
結局どっちを取るかと考えた場合に、あまり取るに足らない欠点
(トランポリンが使えないような切迫した状態では、どーせ
そのプログラム自身でまともなシグナルハンドリングなんて
できっこない)よりも、大きな利点のほうを取ったということでしょう。
また、別の理由としては gcc が stack execution を
必要としていたというのがあったのですが、これも結局は解決。
NetBSD 方面での議論なら、
tech-kern の 4/16 ,4/20,4/21あたり [netbsd.org]と
tech-userlevel の 7/4あたり [netbsd.org]を参照。
で、7/10 あたりに thorpej が実際のコードを突っ込んでます。