問題タブ [aslr]

Windows 7 には、ヒープのランダム化とスタックのランダム化機能があります。どうすればそれを管理できますか？アプリケーションのパフォーマンスにどのように影響しますか? それがどのように機能するかについての詳細情報はどこにありますか?

C++ プログラムの開発に Visual Studio 2008 を使用しています。その機能に対するコンパイラのオプションが見つかりません。

私は、複数のプロセスにまたがる共通のアドレス空間レイアウトを利用できる並列プログラムのランタイムシステムに取り組んでおり、潜在的には複数の（数千の）ノードに分散しています。sysctl -w kernel.randomize_va_space=0多くの場合、この環境用に構築されたソフトウェアは、デフォルトでアドレス空間のランダム化が有効になっているLinuxシステムで実行され、ユーザーはシステム全体（経由など）でアドレス空間のランダム化を無効にしたくない、または無効にできない場合があります。これにより、並列プログラムにいくつかの制限が課せられ、パフォーマンスが低下する可能性があります。したがって、構築するバイナリに対してそれを無効にする方法を理解したいと思います。このソフトウェアは常に制御された環境で実行されているため、セキュリティは問題ではありません。

ET_EXEC、EF_AS_NO_RANDOM（どうやらマージされたことがない？）やなどのさまざまなフラグや変数への参照を見つけましたがPF_RANDOMIZE、これらのフラグを設定するために何ができるかを説明するドキュメントが見つかりません。理想的な答えは、どのコンパイラ/アセンブラ/リンカーフラグが結果のバイナリのランダム化を無効にするか、そしてこれが機能するツールチェーン/カーネルのバージョンを教えてくれるでしょう。次善の策は、バイナリが構築された後に同じことを行うツールです。

誰かがそれを提案すると確信しているので、実行時にこの変更を行うことができることはすでに知っていますがsetarch -R、これを実行可能ファイルに記録することをお勧めします。

トリックを実行する必要があるようにpaxctl -rx見えますが、PaXパッチを含まないカーネルで使用されている現在の方法には適用されないようです。

関数呼び出しなど、コードをどのように変更しますか?

VS2010 でプログラムを作成しており、ビルド ターゲットは .NET 4です。デフォルトでDEP互換性フラグがオンになっていると思います。本当？

.NET はデフォルトでASLRとも互換性がありますか?また、ASLR は私のプロセスに対してデフォルトでオンになっていますか?それとも実行時に要求する必要がありますか?

FreeBSD と大きな mmap で問題が発生しています。Linux では同じ問題は発生しません。

プログラムの起動時に、常に 1 GB のマップを取得できます。ただし、ファイルが置き換えられて再マップされるリロード操作があります。通常、新しいマップは毎回少しだけ大きくなるため、古い mmap の場所にはうまく収まりません。このリマップは、FreeBSD ではしばしば失敗しますが、Linux ではほとんど失敗しません。(ASLR を使用する Linux ではより頻繁に失敗します。FreeBSD はASLRを使用しますか?)

これは、ライブラリが他のライブラリをロードし、プログラムの実行中に仮想メモリ空​​間を断片化するメモリ割り当てが行われたためだと思います。おそらく、これを引き起こす FreeBSD の malloc 実装またはライブラリのロードの特殊性があります。

私はそれが機能する可能性を高めるためにできることを探しています。

私が考えていることの 1 つは、ファイル サイズが実際には 890 MB であっても、常に 1 GB のスペース全体を mmap することです。私がそれを機能させることができれば、新しい 895 MB ファイルを再マップするための 1 GB スロットを常に確保できます。

ASLRとDEPは、ハッカーからアプリケーションを保護するために使用される 2 つの手法です。多くの最新のアプリケーションがセキュリティを意識するようになっているため、これらの手法の重要性が増しています。今のところ、Windows 7 とこれらの手法に焦点を当てています。特に .NET コンパイラ以外の開発者ツールを使用してデスクトップ アプリケーションを開発する場合は、これらの手法をいつ、どのように使用するのが最適なのだろうかと思います。(.NET セキュリティについては、この質問で回答が得られます。) Delphi や C++Builder などのコンパイラだけでなく、他の WIN32 コンパイラにも特に関心があります。基本的に、これらのアプリケーションで DEP と ASLR の両方をサポートするにはどうすればよいでしょうか? また、自分の (WIN32) コード内からこれらのオプションを制御できる方法はありますか?

MSVC では、ベース アドレスのランダム化がデフォルトのオプションです。(VS2005 以降?)

したがって、dll のベース アドレスを手動でリベースすることはもうありません。

しかし、VS2003 を使用するときの読み込みパフォーマンスを改善するために、すべての dll をリベースしました。

ASLR オプションを使用すると、読み込みのパフォーマンスが常に低下しますか?
（もちろん他の特典も受けられます）

ASLRされたdllイメージの32ビットプロセスのベースアドレスを見ました。
完全なランダム化ではありません。確率の1/2をランダム化しただけです。

たとえば、dllをロードすると、画像は0x12345678にロードされます。
そして、画像を再度ロードすると、画像は0x23456789にロードされます。（ベースアドレスが変更されました！）
しかし、画像を再度ロードします
0x12345678
0x23456789
0x12345678
0x23456789
.. ..

なぜ彼らはこのように実装したのですか？
クラッシュレポートの頻度ですか？（再デプロイされたdllと同じクラッシュアドレスを取得するため）

説を聞いたことがあります。アドレス空間の場所のランダム化は、ライブラリを取得し、仮想アドレス空間のランダム化された場所にロードするため、ハッカーがプログラムに穴を見つけた場合でも、return-to-libc 攻撃を実行するための既知のアドレスを持っていません。たとえば反対。しかし、数秒間考えてみると、防御策としては意味がありません。

仮想の TargetLib (libc またはハッカーが探しているその他のもの) が、決定論的なアドレスではなく、ランダム化されたアドレスにロードされているとしましょう。ハッカーは、TargetLib とその中のルーチンがどこにあるかを事前に知りませんが、アプリケーション コードも知りません。TargetLib 内のルーチンを見つけるために、バイナリのどこかにある種のルックアップ テーブルが必要であり、それは決定論的な場所にある必要があります。(または、他の何かによって指されているランダムな場所。必要な数の間接参照を追加できますが、最終的には既知の場所から開始する必要があります。)

これは、攻撃コードを TargetLib の既知の場所に向ける代わりに、ハッカーが行う必要があるのは、アプリケーションのルックアップ テーブルの TargetLib のエントリに攻撃コードを向け、そのポインターをターゲット ルーチンへ逆参照することだけであり、攻撃は妨げられずに進行することを意味します。

ASLR の仕組みについて理解できないことはありますか? 説明したように、セキュリティのイメージを提供するだけで実際の内容を提供するスピード バンプ以上のものであることがわかりません。何か不足していますか？

vspropsファイルを使用してプロジェクトにASLRを追加しようとしています。適用されているファイルに他の設定があるため、ファイルがプロジェクトで使用されていることを確認しました。ファイルを意図的に破損すると、MSVCでプロジェクトを開くときにエラーが発生します。ASLRをに設定すると、下yesに表示されます。RandomizedBaseAddress="2"<Tool Name=VCLinkerTool

しかし...効果はありません。私も置くことができRandomizedBaseAddress="xxxxx"、それは気にしません。リンカの設定が取得されていないかのようです。GenerateDebugInformation="True"また、他のvspropsファイルが使用しているのを見た別の設定を試しましたが、それも無視されます。これは、リンカがvspropsファイルまたはその中のこれらの設定を無視しているようです。

何が得られますか？誰かがこれを見たことがありますか？