I am using IIRF - an ISAPI rewrite filter for pretty URL's. I haven't been able to get much help from the developer on these issues. I'm hoping by making some sense of this dump, so I can find the problematic area in the code and rebuild it myself. I am not super familiar with C, but can get around. Do I need to build this with debug symbols to get anything useful out of the dump?
These stack overflow exceptions are happening on our live production web server, so I'm not able to use debug mode to step into this code. What's happening is my application pool processes (w3wp.exe) are receiving this error event:
A process serving application pool 'dotNET Pool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '6924'. The data field contains the error number.
Can someone help me make some sense of this data? It's a dump from the IIS Debug Diagnostic tool. How do I interpret it and find the source of the exception? It appears to be an exception inside the 3rd party PCRE regular expressions library.
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...]
I believe that I have found the culprit, after tweaking the IIS Debug Diagnostic tools to provide more information, I have found URL's like the following. It appears to be a similar to a SQL injection attack, but I do not believe to be SQL Injection.
[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;
Has anyone seen this type of attack? Do they know what it is? I've tried to decode this using HEX, Base64 and some others, but I'm not coming up with anything except this ASCII text:
èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);
I think the stack overflow is not due to a bug in the rewriter. It is due to a bug in the patterns used in the configuration of the filter configuration.
It is actually easy to create a single regex that loops endlessly, and neither PCRE nor IIRF have a way to prevent that. It is also possible to create logic loops in the rewrite rules, so that you redirect or rewrite endlessly. Again, there's no way for the filter to stop you from shooting yourself in the foot. You have to take care. These risks exist when using any rewriter that depends on PCRE, or any modular regex engine.
The stack overflow is happening in pcre_exec, which is where the regular expression is being executed. It's a degenerate case but one that should be handled in the configuration. A prior rule should have filtered out such invalid cases. Here's a post about using a rewriting filter as a security barrier.
Test early and often. Some people think that because the filter rules are "just configuration", it is not in need of rigorous testing. In general, that's not a safe assumption. Treat the IIRF rules like any code module. You're just using a different language.