IIRF 中的堆栈溢出（C 程序，ISAPI）
我正在使用 IIRF - 一个用于漂亮 URL 的 ISAPI 重写过滤器。 在这些问题上我无法从开发人员那里得到太多帮助。 我希望通过理解这个转储，这样我就可以找到代码中的问题区域并自己重建它。 我对C不是很熟悉，但可以绕过。 我是否需要使用调试符号来构建它才能从转储中获取任何有用的东西？
这些堆栈溢出异常发生在我们的实时生产 Web 服务器上，因此我无法使用调试模式单步执行此代码。 发生的情况是我的应用程序池进程 (w3wp.exe) 收到此错误事件：
为应用程序池“dotNET Pool”提供服务的进程与万维网发布服务发生致命通信错误。 进程 ID 为“6924”。 数据字段包含错误号。
有人可以帮助我理解这些数据吗？ 这是来自 IIS 调试诊断工具的转储。 我如何解释它并找到异常的来源？ 这似乎是第 3 方 PCRE 正则表达式库中的一个例外。
警告 - DebugDiag 无法找到 IsapiRewrite4.dll 的调试符号，因此下面的信息可能不完整。
在 w3wp__PID__3760__Date__06_23_2009__ Time_01_29_55PM__916__Second_Chance_Exception_C00000FD.dmp 中，C:\IIRF1.2.15R5\IsapiRewrite4.dll 中 IsapiRewrite4!pcre_exec+12f9 处的汇编指令导致堆栈溢出异常 (0xC00000FD)当尝试在线程 5< 上写入内存位置 0x00fc2be8 时/p>
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 on this debug process
我相信我已经找到了罪魁祸首，在调整 IIS 调试诊断工具以提供更多信息后，我发现了如下 URL。 这似乎是一种类似于SQL注入的攻击，但我不认为这是SQL注入。
[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;
有人见过这种类型的攻击吗？ 他们知道那是什么吗？ 我尝试使用 HEX、Base64 和其他一些方法对其进行解码，但除了这个 ASCII 文本之外，我没有想到任何内容：
èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);
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...]
Update on this debug process
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%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为堆栈溢出不是由于重写器中的错误所致。 这是由于过滤器配置的配置中使用的模式存在错误。
实际上，创建一个无限循环的正则表达式很容易，PCRE 和 IIRF 都没有办法阻止这种情况。 还可以在重写规则中创建逻辑循环，以便您无限地重定向或重写。 再说一遍，滤镜无法阻止你搬起石头砸自己的脚。 你必须要小心。 使用任何依赖于 PCRE 的重写器或任何模块化正则表达式引擎时，都存在这些风险。
堆栈溢出发生在 pcre_exec 中，这是执行正则表达式的地方。 这是一种退化情况，但应该在配置中处理。 先前的规则应该过滤掉此类无效案例。 这是 关于使用重写过滤器作为安全屏障的帖子。
尽早且经常进行测试。 有人认为，因为过滤规则“只是配置”，所以不需要严格的测试。 一般来说，这不是一个安全的假设。 像对待任何代码模块一样对待 IIRF 规则。 您只是使用不同的语言。
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.
PCRE 重复递归地调用两个函数，直到耗尽堆栈空间。 您可以尝试将重写 DLL 升级到没有错误的版本，或者尝试更改重写规则，以免遇到 PCRE 错误。
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.
看起来您已经让 pcre_exec 递归并耗尽了所有堆栈空间。 我会检查并查看您使用的正则表达式。
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.
根据最底部的堆栈跟踪，看起来程序正在进入无限递归，两个函数互相调用而不终止。 由于最终耗尽可用堆栈，这将导致堆栈溢出异常。
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.
你能找出发送到无限递归中的 URL 吗？ 看起来您有两个相互触发的重写规则。 除非您有 IsapiRewrite4.dll 的源代码，否则它不会有太大帮助 - 您可以获取汇编代码 - 但即使您有源代码（您可以反编译），它也不会'没有帮助，因为我认为您需要查看传递的 URL。
它是否也转储内存（或者你可以让它这样做）。 Arg1、Arg2 或 Arg3 可能是指向 URL 的指针？
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?
所以我相信我已经找到了错误原因。 虽然我不确定这是否仍然是 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 地址，因此我对其进行了翻译：
十六进制到 ASCII：
<块引用>
èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèèè)
然后将西里尔字母转换为俄语：
<块引用>
использован+никнейм+"Rifsadasy";пиктокод+дешифрован;зарегистрировались+100%+(включен+режим+только+регистрации)
然后俄语转英语：
<块引用>
使用昵称“Rifsadasy”； piktokod 解密； 已注册 100 个（仅限模式）
或者，类似地
它的用法是никнейм“Rifsadasy”； пиктокод 它已被解码； 已注册100名（含仅模式注册）
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:
Hex -to- ASCII:
Then Cyrillic to Russian:
Then Russian to English: