0

PAX、DEP、NX、CANARIES などのさまざまなバッファー/ヒープ/スタック保護テクノロジを検討しています。

そして新しい SMEP - http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/

最新のメインストリーム プロセッサで最新のカーネルを使用していると仮定します。さまざまなコンパイラ保護を使用してすべてのアプリを再コンパイルすると仮定します。適切な DEP、ASLR NX ビットを実行すると仮定します。

ほとんどのバッファ オーバーフロー攻撃が失敗すると言うのは合理的ですか? そして、これは将来のシステムで解決されましたか?

当然の結果として、現在実装されている現在の Win7 システムは、特に 32 ビット アプリで ROT やその他の手法に対して絶望的に脆弱であると言うのは本当ですか?

psここでは意図的に「マネージコードは安全です」という議論には立ち入りません

[免責事項] ずさんなコーディングを推奨しているわけではありません。他にもたくさんの攻撃があることに気づきました。私は、既存のシステムが「理想化された」セキュリティ構成をはるかに上回っていることを知っています

4

2 に答える 2

1

いいえ、少なくともアンマネージ コードでは、バッファ オーバーフローは解決された問題ではありません。

リストしたすべてのテクノロジ (DEP/NX、ASLR、Canaries、SMEP) の基本的な問題は、それらが事後に発生することです。根本的な原因 (バッファ オーバーフローとメモリの破損) を防止できないため、バッファ オーバーフローの問題を解決できません。すでに起こっています。

すべてのスキームは単純に「優れた」ものですが、破損が発生した後でも機能するエクスプロイトになる前に障害を検出しようとするか、信頼できる機能するエクスプロイトを設計するのが難しくなりすぎるため、信頼性の低いヒューリスティックな方法です。

たとえば、Windows Vista および 7 の DEP、ASLR、およびカナリアは、ROT およびその他の手法によって回避される可能性があるため、有効なエクスプロイトを作成する難易度が上がるだけです。しかし、難易度の増加はかなり重要です。これがテクニックのポイントです。

元のバッファの破損を防ぐことで問題を根本から解決することに関心がある場合は、それが最も生産的だと思いますが、おそらくマネージ コードの議論に戻ることになるでしょう...

于 2011-07-19T04:32:57.210 に答える
0

これらのテクノロジーがすべて有効で、強力なコンパイラ チェックが実施されている場合、現在の保護を回避するほとんどの方法は無効になりますが、smep の記事が指摘しているように、それは攻撃のハードルを上げるだけであり、新しいものには追加のチェックと複雑さが必要になります。必要な「ほとんど」の条件に対する最善の策は、最終的にはエクスプロイトに必要な複雑さが利用可能なスペースに収まらなくなることです。保護されるエリアやスペースが増えるにつれて、まだそこには達していません.

于 2011-07-18T10:58:27.547 に答える