問題タブ [aslr]

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ここでは意図的に「マネージコードは安全です」という議論には立ち入りません

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

私の知る限り、ASLR ^{アドレス空間レイアウトのランダム化}は、システムの起動ごと (再起動ごと) にのみランダムな再配置を行います。

アドレス空間レイアウトのランダム化 (ASLR)

ASLR は、システムの起動時に実行可能イメージをランダムな場所に移動するため、エクスプロイト コードが予測どおりに動作することが難しくなります。(...)

この場合、Windows を繰り返し再起動してランダム性が発生することを期待せずに、C++ モジュールまたはシステム モジュール(たとえば) に対して ASLR が発生していることを「テスト」または確認するにはどうすればよいでしょうか?kernel32.dll

Android4.0でASLRが追加されました

http://developer.android.com/sdk/android-4.0-highlights.html#DeveloperApis

Afaik、ASLRは主に、バッファオーバーフローの脆弱性を悪用するときに、悪意のあるコードがリークしたり、ペイロードを別のライブラリに配置したりしないようにするのに役立ちます。

ただし、Androidで実行されるほとんどすべてのコードは管理されるため、メモリ管理エラーの影響を受けないようにする必要があります。

おそらくネイティブコードに役立つ可能性があります。Otoh、NDKを利用するプログラムのほとんど（Cで作成されたopenglゲームエンジンなど）には、ユーザー入力などを処理するためのJavaコードのレイヤーがまだあると思いました（ユーザーが提供するファイル/文字列は悪意のあるコードの主なベクトルになる）

明らかに私は私の写真に何かが欠けています

私のアプリケーションは、その作業を実行するために大量のメモリと大きなデータ構造を必要とします。多くの場合、アプリケーションは 1 GB を超えるメモリを必要とし、場合によっては、顧客が数ギガバイトのメモリを持っているため、実際には 64 ビット バージョンのアプリケーションを使用する必要があります。

以前は、メモリが 1.6 ～ 1.7 GB のメモリ使用量に達した場合、それは「メモリ不足」または「メモリ不足」に非常に近い状況であり、メモリを削減する必要があることをユーザーに簡単に説明できました。または 64 ビット版に移行してください。

昨年、アプリケーションがメモリ不足になる前に約 1 GB しか使用しないことが多いことに気付きました。いくつかの調査の結果、この問題の原因はメモリの断片化であると思われました。VMMAP (SysInternals ユーティリティ) を使用してアプリケーションのメモリ使用量を調べたところ、次のような結果が得られました。

オレンジ色の領域は、アプリケーションによって割り当てられたメモリです。紫色の領域は実行コードです。

画像の下半分でわかるように、紫色の領域 (DLL の部分) がさまざまなアドレスにロードされているため、メモリが断片化されています。私の顧客が大量のデータを持っていない場合、これは実際には問題ではありませんが、私の顧客が 1 GB を超えるデータ セットを持っていて、アプリケーションの一部が大きなメモリ ブロック (50 MB など) を必要とする場合、メモリの割り当てに失敗し、アプリケーションがクラッシュする可能性があります。

私のデータ構造のほとんどは STL ベースであり、連続したメモリの大きなチャンクを必要としないことがよくありますが、場合によっては (非常に大きな文字列など)、メモリの連続したブロックが本当に必要になります。残念ながら、このような連続したメモリ ブロックを必要としないようにコードを変更できるとは限りません。

質問は次のとおりです。

• 顧客のコンピューター上のすべての DLL に対して明示的に REBASE を使用せずに、またはすべての DLL を明示的にロードせずに、DLL がメモリにロードされる場所に影響を与えるにはどうすればよいでしょうか。
• 独自のアプリケーション マニフェスト ファイルで DLL のロード アドレスを指定する方法はありますか?
• または、(マニフェスト ファイルを介して) Windows に DLL を分散させないように指示する方法はありますか (この分散は ASLR と呼ばれていると思います)。

もちろん、Windows による DLL の自動/動的ロードに依存しているため、アプリケーションのマニフェスト ファイル内から影響を与えることができるソリューションが最適です。

私のアプリケーションは混合モード (マネージド + アンマネージド) アプリケーションですが、アプリケーションの大部分はアンマネージドです。

誰の提案ですか？

セキュリティ: NX ビット DEPやASLRなどのメカニズムが何年も前から存在しているにも関わらず、スタック実行のセキュリティ上の欠陥についていまだに耳にするのはなぜでしょうか? ハッカーはこれらを回避する方法を見つけましたか?

MS と Adob​​e の比較的最近修正されたセキュリティ上の欠陥に目を通すと、攻撃者がシステムを制御できるエクスプロイトを見つけることができます。これは、バッファ オーバーラン (DEP/NX/ ASLR)?

特定のdllがASLRを使用しているかどうかを確認する方法は？

たとえばkernel32.dllを例にとると、ASLRを使用するかどうか。と他のdllをチェックする方法...

ありがとう ..

私は DLL インジェクション手法について読んでいましたが、この質問を念頭に置いていました。

kernel32.dll に対して ASLR が有効になっている Windows 7 の宛先プロセスに DLL を挿入するとします。

したがって、注入されたコードのどの部分も winapi またはシステム コールを使用できません。これは、インジェクター コードの loadLibrary 関数のアドレスが宛先プロセスの loadLibrary のアドレスと異なるためです。

したがって、そのような呼び出しは機能しCreateRemoteThreadません:

この推論が間違っている場合は訂正してください。

Address Space Layout Randomization (ALSR) により、別のプロセスから fork されたプロセスは、 を呼び出したときに異なるアドレスが返されると予想されますmmap。しかし、私が知ったように、そうではありませんでした。そのために以下のテストプログラムを作成しました。によって返されるすべてのアドレスはmalloc、親と子でまったく同じです。mallocfor cl1、cl2、pl1、pl2mmapは大きなブロックであるため、内部で使用されることに注意してください。

それで、私の質問は、mmapALSR が存在する場合でも異なるアドレスを返さないのはなぜですか。おそらく、ここでのランダム化のシードは、元のプロセスとフォークされたプロセスで同じであるためです。それとも他に理由がありますか？

Windows 7 x64 で ASLR を無効にして、プログラムが共有 CRT を常に同じアドレスにロードするようにするにはどうすればよいですか?

ASLR（アドレス空間配置のランダム化）によると、プロセスが開始するたびにランダムなスタックとヒープの割り当てとページの読み込みを提供し、特定のプロセスの仮想空間にオブジェクトが配置されるアドレスをランダム化します。

しかし、iOSで実行されている私のアプリケーションでは、ObjectAという名前のオブジェクトを作成し、プロセスを数回リロードした後、ObjectAのアドレスがすべて同じであり、ランダム化されていないことがわかりました。

Apple独自のASLR実装はどのように機能しますか？ObjectAのアドレスがすべて同じなのはなぜですか？