Переполнение стека в IIRF (программа на C, ISAPI)

Question

Я использую IIRF - фильтр перезаписи ISAPI для красивых URL. Я не смог получить большую помощь от разработчика по этим вопросам. Я надеюсь, что смогу разобраться в этом дампе, чтобы найти проблемную область в коде и перестроить ее сам. Я не очень знаком с C, но могу обойтись. Нужно ли создавать это с помощью символов отладки, чтобы получить что-нибудь полезное из дампа?

Эти исключения переполнения стека происходят на нашем работающем производственном веб-сервере, поэтому я не могу использовать режим отладки для входа в этот код. Происходит следующее: процессы пула приложений (w3wp.exe) получают это событие ошибки:

Процесс, обслуживающий пул приложений «dotNET Pool», столкнулся с фатальной ошибкой связи со службой публикации в Интернете. Идентификатор процесса был «6924». Поле данных содержит номер ошибки.

Может ли кто-нибудь помочь мне разобраться в этих данных? Это дамп из средства диагностики отладки IIS. Как мне это интерпретировать и найти источник исключения? Похоже, что это исключение внутри сторонней библиотеки регулярных выражений PCRE.

WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.</p> <p>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</p> </blockquote> <pre> 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...] </pre> <p>

<ч /> Обновление этого процесса отладки

Я считаю, что нашел виновника, после настройки инструментов диагностики отладки 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, где выполняется регулярное выражение. Это вырожденный случай, но тот, который должен быть обработан в конфигурации. Предыдущее правило должно было отфильтровать такие недействительные случаи. Вот пост об использовании фильтра перезаписи в качестве защитного барьера .

Тестируйте рано и часто. Некоторые люди думают, что поскольку правила фильтра «просто конфигурация», он не нуждается в тщательном тестировании. В общем, это не безопасное предположение. Относитесь к правилам IIRF как к любому модулю кода. Вы просто используете другой язык.

Answer 2

похоже, что у вас есть pcre_exec рекурсивный и занимающий все пространство стека. Я бы проверил, какие регулярные выражения вы используете.

Answer 3

PCRE повторно вызывает две функции рекурсивно, пока не исчерпает пространство стека. Вы можете либо попытаться обновить библиотеку перезаписи DLL до той, которая не содержит ошибок, или попытаться изменить правила перезаписи, чтобы она не попала в ошибку PCRE.

Answer 4

Итак, я считаю, что нашел причину ошибки. Хотя я не уверен, действительно ли это ошибка в фильтре 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;

Итак, я создал правило перезаписи, чтобы вернуть статус 404 для этого URL.

Но мне нужно было знать, была ли это какая-то атака, я пока не могу быть полностью уверен, но вот что, по-моему, говорит зашифрованная строка. URL пришел с IP-адресов в России, поэтому вот что я сделал, чтобы перевести его:

1. Hex-to- ASCII:

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

2. Тогда кириллица на русском языке:

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

3. Затем с русского на английский:

   используется прозвище "Рифсадасы"; пиктокод расшифровывать; зарегистрирован 100 (только режим)
   или, аналогично
   используется никнейм "Рифсадасы"; пиктокод расшифрован; было зарегистрировано 100 (включен только режим регистрации)

Answer 5

Можете ли вы определить URL, который отправляется в бесконечную рекурсию? Похоже, у вас есть два правила перезаписи, которые запускают друг друга. Если у вас нет исходного кода для IsapiRewrite4.dll, он не сильно поможет - вы можете получить код сборки - но даже если у вас есть исходный код (вы могли бы декомпилировать), он не будет помочь, потому что я думаю, что вам нужно увидеть URL, который был передан.

Это также дамп памяти (или вы могли бы сделать это сделать). Arg1, Arg2 или Arg3 может быть указателем на URL?

Answer 6

Исходя из этой трассировки стека в самом низу, похоже, что программа входит в бесконечную рекурсию с двумя функциями, которые вызывают друг друга без завершения. Это приведет к исключению переполнения стека из-за нехватки доступного стека.