تجاوز سعة المكدس في IIRF (برنامج C, ISAPI)

Question

أنا باستخدام IIRF - ISAPI كتابة تصفية جدا URL.لم أكن قادرة على الحصول على الكثير من المساعدة من المطور على هذه القضايا.أتمنى من خلال جعل بعض الشعور من هذا المكان حتى يمكنني العثور على المنطقة إشكالية في قانون وإعادة بنائه نفسي.أنا لست سوبر دراية ج ، ولكن يمكن الحصول على جميع أنحاء.هل أنا بحاجة إلى بناء هذا مع رموز التصحيح للحصول على أي شيء مفيد من النفاية ؟

هذه تجاوز سعة مكدس استثناءات تحدث في حياتنا الإنتاج خادم الويب ، لذلك أنا لست قادرا على استخدام وضع التصحيح على خطوة في هذا القانون.ما يحدث هو تجمع التطبيقات العمليات (w3wp.exe) يتم تلقي هذا الخطأ الحدث:

عملية تخدم تجمع التطبيقات 'dotNET تجمع' عانى قاتلة خطأ في الاتصال مع "خدمة نشر ويب".كان معرف العملية '6924'.حقل البيانات يحتوي على رقم الخطأ.

شخص ما يمكن أن تساعدني جعل بعض الشعور من هذه البيانات ؟ هذا تفريغ من IIS تصحيح أداة تشخيصية.كيف يمكنني تفسير ذلك على مصدر استثناء ؟ يبدو أن استثناء داخل 3rd الطرف PCRE التعبيرات العادية المكتبة.

WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

في w3wp__PID__3760__التاريخ__06_23_2009__ الوقت_01_29_55PM__916__الثاني_الفرصة_استثناء_C00000FD.dmp الجمعية التدريس في IsapiRewrite4!pcre_exec+12f9 في C:\IIRF1.2.15R5\IsapiRewrite4.dll وقد تسبب استثناء تجاوز سعة مكدس (0xC00000FD) عند محاولة الكتابة إلى موقع الذاكرة 0x00fc2be8 على الموضوع 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 تصحيح أدوات التشخيص إلى تقديم المزيد من المعلومات ، لقد وجدت رابط مثل التالية.يبدو أن غرار الهجوم حقن 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;

وقد أي شخص ينظر إلى هذا النوع من الهجوم ؟ هل تعرف ما هو ؟ حاولت فك هذا باستخدام عرافة ، Base64 و بعض الآخرين, ولكن أنا لا يأتي مع أي شيء ما عدا هذا نص ASCII:

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

Answer 1

أعتقد أن تجاوز سعة المكدس ليس بسبب خلل في مصحح.هو بسبب خلل في الأنماط المستخدمة في التكوين من تكوين عامل تصفية.

هو في الواقع من السهل إنشاء واحد باستخدام التعابير المنطقية التي لا نهاية حلقات ولا PCRE ولا IIRF طريقة لمنع ذلك.ومن الممكن أيضا لإنشاء المنطق الحلقات في إعادة كتابة القواعد حتى يتسنى لك إعادة توجيه أو إعادة كتابة ما لا نهاية.مرة أخرى, ليس هناك طريقة التصفية لوقف لكم من اطلاق النار على نفسك في القدم.عليك أن تأخذ الرعاية.هذه المخاطر موجودة عند استخدام أي مصحح هذا يعتمد على PCRE ، أو أي وحدات regex المحرك.

تجاوز سعة المكدس يحدث في pcre_exec حيث التعبير العادي يجري تنفيذها.انها تتحول القضية ولكن ذلك يجب أن يتم التعامل معها في التكوين.قبل الحكم يجب أن تخرج مثل هذه غير صالحة الحالات.هنا بعد حول استخدام إعادة كتابة تصفية حاجزا أمنيا.

الاختبار في وقت مبكر و في كثير من الأحيان.بعض الناس يعتقدون أنه بسبب تصفية القواعد "فقط التكوين" ، ليس في حاجة إلى اختبارات صارمة.عموما هذا ليس مجرد افتراض.علاج IIRF القواعد مثل أي رمز وحدة.أنت فقط باستخدام لغة مختلفة.

Answer 2

PCRE هو استدعاء اثنين من المهام بشكل متكرر مرارا وتكرارا, حتى نفاد مساحة مكدس.يمكنك إما محاولة ترقية كتابة DLL غير عربات التي تجرها الدواب ، أو محاولة تغيير إعدادات إعادة كتابة القواعد بحيث لا تصل PCRE علة.

Answer 3

يبدو أنك قد حصلت على pcre_exec recursing و استخدام كافة مساحة مكدس.وأود أن تحقق لمعرفة ما التعابير العادية تستخدمه.

Answer 4

على أساس أن تتبع المكدس في الجزء السفلي جدا ، يبدو أن البرنامج هو الذهاب إلى لانهائية العودية, مع اثنين من الوظائف التي يدعو بعضها البعض دون إنهاء.وهذا سوف يسبب استثناء تجاوز سعة مكدس بسبب تشغيل في نهاية المطاف المتاحة المكدس.

Answer 5

يمكنك معرفة عنوان URL الذي يرسل إلى لانهائية العودية?يبدو أن لديك اثنين من كتابة القواعد التي تسبب بعضها البعض.إلا إذا كان لديك مصدر IsapiRewrite4.dll انها لن تساعد كثيرا -- يمكنك الحصول على رمز التجميع -- ولكن حتى إذا كان لديك مصدر (أنت يمكن أن فك) ، فإنه لن يساعد لأنني أعتقد أنك بحاجة إلى أن نرى URL التي تمت.

فعل ذلك أيضا تفريغ الذاكرة (أو يمكنك جعلها تفعل ذلك).Arg1, Arg2, أو Arg3 قد تكون مؤشر إلى عنوان الموقع ؟

Answer 6

لذلك أعتقد أنني قد وجدت سبب الخطأ.على الرغم من أنني لست متأكدا إذا كان هذا هو حقا خطأ في IIRF تصفية ISAPI?فإنه على الأقل يجب أن لا تكرار خلال كتابة وظائف مرات عديدة أن يؤدي تجاوز سعة مكدس.

لا يمكن إعادة إنشاء الخطأ كنت أرى في سجل الأحداث عن طريق طلب هذا العنوان على الخادم:[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;

حتى لقد خلق كتابة القاعدة على 404 وضع عنوان URL هذا.

ولكن أنا في حاجة إلى معرفة ما إذا كان هذا النوع من الهجوم, أنا لا يمكن أن يكون متأكد تماما حتى الآن, ولكن هنا هو ما أعتقد أن سلسلة المشفرة يقول.URL كانت قادمة من عناوين IP في روسيا ، حتى هنا هو ما فعلته ترجمته:

1. عرافة -إلى - ASCII:

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

2. ثم السيريلية الروسية:

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

3. ثم الروسية إلى الإنجليزية:

   استخدام لقب "Rifsadasy";piktokod فك تشفير;مسجلة 100 (وضع فقط)
   أو بالمثل
   يتم استخدامه никнейм "Rifsadasy";пиктокод يتم فك الشفرة;تم تسجيل 100 (وضع التسجيل فقط غير المدرجة)