1

我正在使用IIRF——一个用于漂亮 URL 的 ISAPI 重写过滤器。在这些问题上，我无法从开发人员那里获得太多帮助。我希望通过对这个转储有所了解，这样我就可以在代码中找到有问题的区域并自己重建它。我对C不是超级熟悉，但可以解决。我是否需要使用调试符号构建它才能从转储中获取任何有用的信息？

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

为应用程序池“dotNET 池”提供服务的进程与万维网发布服务发生了致命的通信错误。进程 ID 为“6924”。数据字段包含错误号。

有人可以帮我理解这些数据吗？它是来自 IIS 调试诊断工具的转储。我如何解释它并找到异常的来源？它似乎是第 3 方 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 中，这是执行正则表达式的地方。这是一种退化的情况，但应该在配置中处理。先前的规则应该已经过滤掉了这种无效的情况。这是一篇关于使用重写过滤器作为安全屏障的帖子。

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.

于 2009-06-30T01:42:11.037 回答
2

PCRE 反复递归调用两个函数，直到堆栈空间用完。您可以尝试将 Rewrite DLL 升级到没有错误的版本，或者尝试更改您的重写规则，使其不会遇到 PCRE 错误。

于 2009-06-24T18:33:46.770 回答
2

看起来您已经使 pcre_exec 递归并用完了所有堆栈空间。我会检查并查看您使用的是什么正则表达式。

于 2009-06-24T18:33:50.450 回答
1

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

于 2009-06-24T18:34:58.873 回答
1

你能找出发送到无限递归的 URL 吗？看起来您有两个相互触发的重写规则。除非你有 IsapiRewrite4.dll 的源代码，否则它不会有太大帮助——你可以得到汇编代码——但即使你有源代码（你可以反编译），它也无济于事，因为我认为你需要查看通过的 URL。

它是否也转储内存（或者你可以让它这样做）。Arg1、Arg2 或 Arg3 可能是指向 URL 的指针？

于 2009-06-24T19:16:40.340 回答
1

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

我可以通过在我的服务器上请求此 URL 来重现我在事件日志中看到的错误：[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；

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

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

  1. 十六进制到 ASCII：

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

  2. 然后是西里尔文到俄文：

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

  3. 然后俄语到英语：

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

于 2009-06-25T22:34:12.633 回答