1

私はIIRFを使用しています-きれいなURL用のISAPI書き換えフィルターです。私はこれらの問題について開発者から多くの助けを得ることができませんでした。このダンプの意味を理解して、コード内の問題のある領域を見つけて自分で再構築できるようにしたいと思っています。私はCにあまり詳しくありませんが、回避することはできます。ダンプから何か有用なものを引き出すために、デバッグシンボルを使用してこれを構築する必要がありますか?

これらのスタックオーバーフロー例外は、ライブの本番Webサーバーで発生しているため、デバッグモードを使用してこのコードにステップインすることはできません。何が起こっているのかというと、アプリケーションプールプロセス(w3wp.exe)が次のエラーイベントを受信して​​います。

アプリケーションプール「dotNETプール」にサービスを提供するプロセスで、World Wide WebPublishingServiceとの致命的な通信エラーが発生しました。プロセスIDは「6924」でした。データフィールドにはエラー番号が含まれています。

誰かが私がこのデータを理解するのを手伝ってもらえますか?これは、IISデバッグ診断ツールからのダンプです。どうすればそれを解釈して例外の原因を見つけることができますか?サードパーティのPCRE正規表現ライブラリ内では例外のようです。

WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

In w3wp__PID__3760__Date__06_23_2009__ Time_01_29_55PM__916__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15R5\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x00fc2be8 on thread 5

Type of Analysis Performed   Crash Analysis 
Machine Name  WEB
Operating System   Windows Server 2003 Service Pack 2 
Number Of Processors   4 
Process ID   8056 
Process Image   c:\WINDOWS\system32\inetsrv\w3wp.exe 
System Up-Time   0 day(s) 09:26:25 
Process Up-Time   0 day(s) 02:17:00 

Thread 4 - System ID 6624
Entry point   w3tp!THREAD_MANAGER::ThreadManagerThread 
Create time   6/23/2009 11:12:56 AM 
Time spent in user mode   0 Days 0:0:40.906 
Time spent in kernel mode   0 Days 0:0:6.312 

Function                         Arg 1        Arg 2        Arg 3     Source 
IsapiRewrite4!pcre_exec+12f9     08166a27     01b6741f     081669b8    
IsapiRewrite4!pcre_exec+2779     08166a27     01b6746b     081669b8    
IsapiRewrite4!pcre_exec+1660     08166a26     01b6741f     081669b8    
IsapiRewrite4!pcre_exec+2779     08166a26     01b6746b     081669b8    
IsapiRewrite4!pcre_exec+1660     08166a25     01b6741f     081669b8    
IsapiRewrite4!pcre_exec+2779     08166a25     01b6746b     081669b8    
IsapiRewrite4!pcre_exec+1660     08166a24     01b6741f     081669b8    
IsapiRewrite4!pcre_exec+2779     08166a24     01b6746b     081669b8    
IsapiRewrite4!pcre_exec+1660     08166a23     01b6741f     081669b8    
IsapiRewrite4!pcre_exec+2779     08166a23     01b6746b     081669b8    
IsapiRewrite4!pcre_exec+1660     08166a22     01b6741f     081669b8    
[...snip...]


このデバッグプロセスの更新

IISデバッグ診断ツールを調整してより多くの情報を提供した後、原因を見つけたと思います。次のようなURLを見つけました。SQLインジェクション攻撃に似ているように見えますが、SQLインジェクションではないと思います。

[original_url]/Forum+Result:+%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0%ED+%ED%E8 %EA%ED%E5%E9%EC+%22Rifsadasy%22;%EF%E8%EA%F2%EE%EA%EE%E4+%E4%E5%F8%E8 %F4%F0%EE%E2%E0%ED;%E7%E0%F0%E5%E3%E8%F1%F2%F0%E8%F0%EE%E2%E0%EB%E8%F1 %FC+100%25+%28%E2%EA%EB%FE%F7%E5%ED+%F0%E5%E6%E8%EC+%F2%EE%EB%FC%EA%EE +%F0%E5%E3%E8%F1%F2%F0%E0%F6%E8%E8%29;

誰かがこのタイプの攻撃を見たことがありますか?彼らはそれが何であるか知っていますか?HEX、Base64などを使用してこれをデコードしようとしましたが、このASCIIテキスト以外は何も思いつきません。

èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);

4

6 に答える 6

3

スタック オーバーフローは、リライタのバグによるものではないと思います。これは、フィルター構成 の構成で使用されるパターンのバグによるものです。

実際、エンドレスにループする単一の正規表現を作成するのは簡単ですが、PCRE にも IIRF にもそれを防ぐ方法はありません。書き換えルールに論理ループを作成して、無限にリダイレクトまたは書き換えることも可能です。繰り返しますが、フィルターが自分の足を撃つことを止める方法はありません. あなたは世話をしなければなりません。これらのリスクは、PCRE に依存するリライターやモジュラー正規表現エンジンを使用する場合に存在します。

スタック オーバーフローは、正規表現が実行されている pcre_exec で発生しています。これは退化したケースですが、構成で処理する必要があります。以前のルールで、このような無効なケースを除外する必要がありました。これは、書き換えフィルターをセキュリティ バリアとして使用することに関する投稿です。

早期に頻繁にテストします。フィルタ ルールは「単なる設定」であるため、厳密なテストは必要ないと考える人もいます。一般に、これは安全な仮定ではありません。IIRF ルールを他のコード モジュールと同様に扱います。別の言語を使用しているだけです。

于 2009-06-30T01:42:11.037 に答える
2

PCREは、スタックスペースがなくなるまで、2つの関数を繰り返し繰り返し呼び出します。リライトDLLをバグのないものにアップグレードするか、PCREバグにぶつからないようにリライトルールを変更してみてください。

于 2009-06-24T18:33:46.770 に答える
2

pcre_execが繰り返し使用され、スタックスペースがすべて使い果たされているようです。使用している正規表現を確認します。

于 2009-06-24T18:33:50.450 に答える
1

一番下のスタックトレースに基づくと、プログラムは無限再帰になり、2つの関数が終了せずに相互に呼び出しているように見えます。これにより、最終的に使用可能なスタックが不足するため、スタックオーバーフロー例外が発生します。

于 2009-06-24T18:34:58.873 に答える
1

無限再帰に送られている URL を特定できますか? 互いにトリガーしている 2 つの書き換えルールがあるようです。IsapiRewrite4.dll のソースがない限り、あまり役に立ちません。アセンブリ コードにアクセスできます。ただし、ソースがあったとしても (逆コンパイルできます)、役に立ちません。渡された URL を確認する必要があります。

メモリもダンプしましたか(または、そうするようにできますか)。Arg1、Arg2、または Arg3 は、URL へのポインターである可能性がありますか?

于 2009-06-24T19:16:40.340 に答える
1

だから私は原因エラーを発見したと信じています。これが本当にIIRF ISAPIフィルターのバグなのかどうかはわかりませんが? 少なくとも、書き換え関数を何度も繰り返してスタック オーバーフローを引き起こすべきではありません。

サーバーで [original_url]/Forum+Result:+%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0% という URL をリクエストすることで、イベント ログに表示されていたエラーを再現できます。 ED+%ED%E8 %EA%ED%E5%E9%EC+%22Rifsadasy%22;%EF%E8%EA%F2%EE%EA%EE%E4+%E4%E5%F8%E8 %F4%F0%EE %E2%E0%ED;%E7%E0%F0%E5%E3%E8%F1%F2%F0%E8%F0%EE%E2%E0%EB%E8%F1 %FC+100%25+%28 %E2%EA%EB%FE%F7%E5%ED+%F0%E5%E6%E8%EC+%F2%EE%EB%FC%EA%EE +%F0%E5%E3%E8%F1%F2% F0%E0%F6%E8%E8%29;

そこで、この URL に対して 404 ステータスを返す書き換えルールを作成しました。

しかし、これが何らかの攻撃であったかどうかを知る必要がありました。まだ完全にはわかりませんが、暗号化された文字列は次のように言っていると思います。URL はロシアの IP アドレスから来ていたので、翻訳するために行ったことは次のとおりです。

  1. 16 進数から ASCII へ:

    èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüî+ðåãèñòðàöèè)

  2. 次に、キリル文字からロシア語へ:

    использован+никнейм+"Rifsadasy";пиктокод+дешифрован;зарегистрировались+100%+(включен+режим+только+регистрации)

  3. 次に、ロシア語から英語へ:

    ニックネーム「Rifsadasy」を使用。pictokod 復号化; 登録済み 100 (モードのみ)
    または、同様
    に使用されます никнейм "Rifsadasy"; пиктокод デコードされます。登録数 100件(モードのみの登録含む)

于 2009-06-25T22:34:12.633 に答える