アカウント名:
パスワード:
ヒープをターゲットにした攻撃の可能性は残りますから注意は必要ですが、オーバーフローを起こしそうなコ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
コード実行の制限 (スコア:2, 参考になる)
ヒープをターゲットにした攻撃の可能性は残りますから注意は必要ですが、オーバーフローを起こしそうなコ
の
Re:コード実行の制限 (スコア:2, 参考になる)
> というのが面白いです。バッファオーバーフローに基づいた攻撃が
> ほとんど無効化されます。
これって大昔からあちこちで提案されているけど、signal trampolineとかの
メカニズムでスタックのコード実行が必要となるために、いつもお流れと
なっています。
今回、OpenBSDがスタック上でのコード実行を不可能としたいきさつが
気になりますね。
http://search.luky.org/linux-kernel.2001/msg16453.html
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26428+0+archive/1998/freebsd-security/19980719.freebsd-security
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 が実際のコードを突っ込んでます。
Re:コード実行の制限 (スコア:0)