IIRF中的堆栈溢出（C程序，ISAPI）

Question

我正在使用IIRF - 一个用于漂亮网址的ISAPI重写过滤器。在这些问题上，我无法从开发人员那里获得太多帮助。我希望能够理解这个转储，所以我可以在代码中找到有问题的区域并自己重建它。我不是很熟悉C，但可以绕过。我是否需要使用调试符号构建它以从转储中获得有用的东西？

这些堆栈溢出异常发生在我们的实时生产Web服务器上，因此我无法使用调试模式进入此代码。发生的事情是我的应用程序池进程（w3wp.exe）收到此错误事件：

  

为应用程序池“dotNET Pool”提供服务的进程与World Wide Web Publishing服务发生了致命的通信错误。进程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%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);

Answer 1

我认为堆栈溢出不是由于 重写器 中的错误造成的。这是由于 过滤器配置的配置 中使用的模式中的错误。

创建一个无休止循环的单一正则表达式实际上很容易，而且PCRE和IIRF都没有办法防止这种情况发生。也可以在重写规则中创建逻辑循环，以便您无限重定向或重写。再一次，过滤器无法阻止你在脚下射击。你必须要小心。使用依赖于PCRE的任何重写器或任何模块化正则表达式引擎时，存在这些风险。

堆栈溢出发生在pcre_exec中，这是执行正则表达式的地方。这是一个退化的情况，但应该在配置中处理。先前的规则应该过滤掉这种无效的情况。这是a post about using a rewriting filter as a security barrier。

早期经常测试。有些人认为，因为过滤规则是“只是配置”，所以不需要严格的测试。一般来说，这不是一个安全的假设。像任何代码模块一样对待IIRF规则。你只是使用不同的语言。

Answer 2

PCRE重复递归调用两个函数，直到它用完堆栈空间。您可以尝试将Rewrite DLL升级到没有错误的DLL，或尝试更改重写规则，以免它碰到PCRE错误。

Answer 3

看起来你已经让pcre_exec递归并耗尽了你所有的堆栈空间。我会查看你正在使用的正则表达式。

Answer 4

基于最底层的堆栈跟踪，看起来程序进入无限递归，两个函数相互调用而不终止。由于最终耗尽可用堆栈，这将导致堆栈溢出异常。

Answer 5

你能算出发送到无限递归的URL吗？看起来你有两个相互触发的重写规则。除非你有IsapiRewrite4.dll的源代码，否则它不会有太多帮助 - 你可以使用汇编代码 - 但即使你有源代码（你可以反编译），它也会赢得'帮助，因为我认为你需要看到传递的URL。

它是否也会转储内存（或者你可以做到这一点）。 Arg1，Arg2或Arg3可能是指向URL的指针？

Answer 6

所以我相信我找到了原因错误。虽然我不确定这是否仍然是IIRF ISAPI过滤器中的错误？它至少不应该遍历重写函数很多次，导致堆栈溢出。

我可以通过在我的服务器上请求此URL来重现我在事件日志中看到的错误： [original_url] /论坛+结果：+％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;

所以我创建了一个重写规则来返回此URL的404状态。

但我需要知道这是否是某种类型的攻击，我还不能完全确定，但这是我认为加密的字符串所说的。该URL来自俄罗斯的IP地址，所以我在这里翻译它：

1. Hex -to-ASCII：

     

   èñïîëüçîâàí+íèêíåéì+ “Rifsadasy”;ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+ 100％+（âêëþ÷AI +ðåæèì+òîëüêî+ðåãèñòðàöèè）

2. 然后西里尔语到俄语：

     

   использован+никнейм+ “Rifsadasy”;пиктокод+дешифрован;зарегистрировались+ 100％+（включен+режим+только+регистрации）

3. 然后俄语译成英语：

     

   使用昵称“Rifsadasy”; piktokod解密;注册100（仅限模式）
     或者，类似的   使用никнейм“Rifsadasy”; пиктокод它被解码;注册100（仅包括模式注册）