Stack-Überlauf in IIRF (ein C-Programm, ISAPI)

Question

Ich verwende IIRF - ein ISAPI-Filter für pretty URLs umschreiben. Ich konnte nicht viel Hilfe vom Entwickler zu diesen Problemen bekommen. Ich hoffe, dass ich mir einen Eindruck von diesem Dump verschaffe, damit ich den problematischen Bereich im Code finden und ihn selbst wieder aufbauen kann. Ich bin mit C nicht sonderlich vertraut, kann aber umgehen. Muss ich das mit Debug-Symbolen erstellen, um nützliche Informationen aus dem Speicherauszug zu erhalten?

Diese Stapelüberlauf-Ausnahmen finden auf unserem Live-Produktions-Webserver statt. Daher kann ich den Debug-Modus nicht verwenden, um in diesen Code zu gelangen. Was geschieht, ist meine Anwendungspoolprozesse (w3wp.exe), um dieses Fehlerereignis erhalten:

Ein Prozess für Anwendungspool ‚dotNET Pool‘ erlitt einen tödlichen Kommunikationsfehler mit dem World Wide Web-Publishing-Dienst. Die Prozess-ID war "6924". Das Datenfeld enthält die Fehlernummer.

Kann mir jemand helfen, diese Daten zu verstehen? Es ist ein Speicherauszug aus dem IIS Debug Diagnostic Tool. Wie interpretiere ich es und finde die Quelle der Ausnahme? Es scheint eine Ausnahme innerhalb der regulären PCRE-Expressions-Bibliothek von Drittanbietern zu sein.

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...] 

---

Update zu diesem Debug-Prozess

Ich glaube, dass ich die Schuldigen gefunden zu haben, nachdem sie die IIS Debug Diagnostic Tools Tweaking weitere Informationen zur Verfügung zu stellen, ich habe URLs gefunden wie folgende. Es scheint einem SQL Injection Angriff ähnlich zu sein, aber ich glaube nicht, SQL Injection zu sein.

[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;

Hat jemand diese Art von Angriff gesehen? Wissen sie was es ist? Ich habe versucht, dies mit HEX, Base64 und einige andere zu entschlüsseln, aber ich komme nicht mit irgendetwas außer diesem ASCII-Text auf:

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

Answer 1

Ich denke, der Stack-Überlauf einen Fehler in die rewriter nicht fällig ist. Es ist aufgrund eines Fehlers in die Muster in der Konfiguration der Filterkonfiguration verwendet.

Es ist eigentlich einfach, eine einzige Regex zu erstellen, die endlos loopt, und weder PCRE noch IIRF können dies verhindern. Es ist auch möglich, logische Schleifen in den Umschreibungsregeln zu erstellen, so dass Sie endlos umleiten oder neu schreiben können. Auch hier gibt es keine Möglichkeit, dass der Filter Sie daran hindert, sich selbst in den Fuß zu schießen. Du musst aufpassen.Diese Risiken bestehen, wenn Sie einen Rewriter verwenden, der von PCRE oder einer modularen Regex-Engine abhängt.

Der Stapelüberlauf findet in pcre_exec statt, wo der reguläre Ausdruck ausgeführt wird. Es ist ein degenerierter Fall, der aber in der Konfiguration behandelt werden sollte. Eine vorherige Regel hätte solche ungültigen Fälle ausfiltern sollen. Hier ist a post about using a rewriting filter as a security barrier.

Testen Sie früh und oft. Einige Leute denken, dass, weil die Filterregeln "nur Konfiguration" sind, es keine strengen Tests benötigt. Im Allgemeinen ist das keine sichere Annahme. Behandle die IIRF-Regeln wie jedes Code-Modul. Du benutzt nur eine andere Sprache.

Answer 2

PCRE zwei Funktionen rekursiv wiederholt ruft , bis der Stapelspeicher leer ist. Sie können entweder versuchen, die Rewrite-DLL auf eine Version zu aktualisieren, die nicht fehlerbehaftet ist, oder versuchen, Ihre Rewrite-Regeln so zu ändern, dass der PCRE-Fehler nicht auftritt.

Answer 3

sieht aus, als ob du pcre_exec rekursiv verwendest und all deinen Stack-Platz aufgebraucht hast. Ich würde überprüfen und sehen, welche regulären Ausdrücke Sie verwenden.

Answer 4

Basierend auf dieser Stack-Trace ganz unten, sieht es aus wie das Programm in unendliche Rekursion geht, mit zwei Funktionen, die sich gegenseitig aufrufen, ohne zu beenden. Dies führt zu einer Stapelüberlauf-Ausnahme, da der verfügbare Stapel schließlich ausgeht.

Answer 5

Können Sie herausfinden, welche URL in die unendliche Rekursion gesendet wird? Es sieht so aus, als hättest du zwei Rewrite-Regeln, die sich gegenseitig auslösen. Es sei denn, Sie haben die Quelle für IsapiRewrite4.dll, es wird nicht viel helfen - Sie können zum Assembly-Code gelangen - aber selbst wenn Sie die Quelle (Sie könnte dekompilieren), wird es nicht helfen, weil ich denke, dass Sie die URL sehen müssen wurde bestanden.

Hat es auch Speicher dump (oder könnten Sie es tun). Arg1, Arg2 oder Arg3 könnten ein Zeiger auf die URL sein?

Answer 6

Also ich glaube, ich habe den Ursache Fehler gefunden. Obwohl ich nicht sicher bin, ob das immer noch ein Fehler im IIRF ISAPI Filter ist? Es sollte zumindest nicht so oft die Rewrite-Funktionen durchlaufen, dass es einen Stack-Overflow verursacht.

Ich kann den Fehler, den ich im Ereignisprotokoll sah, reproduzieren, indem ich diese URL auf meinem Server anfordere: [original_url]/Forum + Ergebnis: +% 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;

Also habe ich eine Rewrite-Regel erstellt, um einen 404-Status für diese URL zurückzugeben.

Aber ich musste wissen, ob dies eine Art von Angriff war, kann ich noch nicht ganz sicher sein, aber hier ist, was ich denke, die verschlüsselte Zeichenfolge sagt. Die URL wurde von IP-Adressen in Russland kommen, hier so ist, was ich habe, es zu übersetzen getan:

1. Hex -zu-- ASCII:

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

2. Dann Cyrillic Russisch:

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

3. Dann Russisch nach Englisch:

   verwendet Spitzname "Rifsadasy"; piktokod entschlüsseln; registriert 100 (nur Modus)
   oder ähnlich
   Es wird никнейм "Rifsadasy" verwendet; пиктокод wird es decodiert; registriert wurden 100 (Registrierung des Modus nur enthalten ist)