Stack overflow in IIRF (a C program, ISAPI)

Answer 1

PCRE is calling two functions recursively repeatedly, until it runs out of stack space. You can either try to upgrade the Rewrite DLL to one that isn't buggy, or try to change your rewrite rules so that it doesn't hit the PCRE bug.

Answer 2

looks like you've got pcre_exec recursing and using up all of your stack space. I would check and see what regular expressions you are using.

Answer 3

Based on that stack trace at the very bottom, it looks like the program is going into infinite recursion, with two functions that are calling each other without terminating. This will cause a stack overflow exception due to eventually running out of available stack.

Answer 4

Can you figure out the URL that's sending into the infinite recursion? It looks like you have two rewrite rules that are triggering each other. Unless you have the source to IsapiRewrite4.dll, it's not going to help much -- you can get to the assembly code -- but even if you had the source (you could decompile), it won't help, because I think you need to see the URL that got passed.

Did it also dump memory (or could you make it do that). Arg1, Arg2, or Arg3 might be a pointer to the URL?

Answer 5

So I believe I have found the cause error. Though I'm not sure if this is still really a bug in IIRF ISAPI filter? It at least should not iterate through the rewrite functions so many times that it causes a stack overflow.

I can reproduce the error I was seeing in the event log by requesting this URL on my server: [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;

So I've created a rewrite rule to return a 404 status for this URL.

But I needed to know if this was some type of attack, I cannot be fully sure yet, but here is what I think the encrypted string says. The URL was coming from IP addresses in Russia, so here is what I've done to translate it:

1. Hex -to- ASCII:

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

2. Then Cyrillic to Russian:

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

3. Then Russian to English:

   used nickname "Rifsadasy"; piktokod decrypt; registered 100 (mode only)
   or, similarly
   It is used никнейм "Rifsadasy"; пиктокод it is decoded; were registered 100 (the mode only registration is included)

Answer 6

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.