التين. 1. كدمات ، ولكن لم ينكسر. تحولت حاسبة Windows ، التي تم نشر رمزها مؤخرًا على Github ، إلى واحد من تطبيقين تم اختبارهما ولم يتم تعليقهما ولم يتعارضا مع fuzzer لرسائل النافذة التي تم تطويرها في عام 2000. حجم النافذة الموسع خصيصا لإظهار التحف المذهلة

لقد حان الوقت للجزء الثاني من جهودنا لاختبار التقنيات القديمة المذهلة على الأنظمة الحديثة. إذا فاتتك ، إليك الجزء الأول . هذه المرة سنختبر نظام التشغيل Windows 10 باستخدام تقنيات مضحكة من مقال "البحث التجريبي عن موثوقية تطبيقات Windows NT باستخدام اختبار عشوائي" (يُعرف باسم "تقرير Fuzzing NT") بقلم جوستين فورستر وبارتون ميلر ، الذي نشر في عام 2000.

قام الباحثون باختبار 33 تطبيقًا من Windows NT وإصدارًا سابقًا من نظام التشغيل Windows 2000 لمعرفة مدى قابلية رسائل الإطار المشوهة وأحداث الماوس ولوحة المفاتيح العشوائية. نظرًا لأن Dr. Miller نشر رمز fuzzer ، فقد استخدمنا بالضبط نفس الأدوات التي استخدمها المؤلفون الأصليون للبحث عن الأخطاء في تطبيقات Windows الحديثة.

النتائج متطابقة تقريبًا: قبل 19 عامًا ، تعطل أو تعطل 100٪ من التطبيقات التي تم اختبارها عندما واجهوا رسائل نافذة مشوهة. اليوم ، انخفض نفس الشغف أو علق 93٪ من التطبيقات المختبرة. وقفت اثنين فقط ، بما في ذلك حاسبة صديقنا القديم (الشكل 1). وجدنا أيضًا خللًا (ولكن ليس مشكلة أمنية) على Windows.

مقدمة موجزة لنظام التشغيل Windows

إذن ما هي رسائل النافذة ولماذا تتسبب في تعطل البرنامج؟

تطبيقات Windows GUI تعتمد على الأحداث: حركات الماوس ، الضغط على الزر ، ضغطات المفاتيح ، وما إلى ذلك. لن يقوم التطبيق الذي يحركه الحدث بأي شيء حتى يتلقى حدثًا. بمجرد استلام الحدث ، ينفذ التطبيق الإجراء بناءً على الحدث ، ثم يتوقع أحداث أخرى. يبدو مألوفا؟ حصلت هذه البنية على حياة ثانية على الأنظمة الأساسية مثل node.js.

رسائل النافذة هي طريقة لإعلام أحداث Windows . كل واحد منهم لديه رمز رقمي يرتبط بحدث معين . كل رسالة لها معلمة واحدة أو أكثر ، والتي تسمى اصطلاحًا بـ lParam و wParam . وهي تحدد معلومات أكثر تفصيلاً حول الحدث. أمثلة على هذه المعلومات هي إحداثيات حركة الماوس ، أي المفتاح مضغوط أو أي نص لعرضه في النافذة. يمكن إرسال هذه الرسائل بواسطة البرنامج نفسه أو نظام التشغيل أو البرامج الأخرى. يمكن أن يصلوا في أي وقت وبأي ترتيب ويجب معالجته بواسطة التطبيق على جانب المتلقي.

الآثار المترتبة على السلامة

قبل نظام التشغيل Windows Vista ، يمكن لعملية منخفضة الامتياز إرسال رسالة إلى عملية عالية الامتياز. باستخدام المزيج الصحيح من الرسائل ، يمكنك تنفيذ التعليمات البرمجية في هذه العملية. في نظام التشغيل Vista ، كانت هذه "الهجمات الهدامة" محمية بشكل كبير بواسطة UIPI وعزل خدمات النظام في جلسة منفصلة.

من غير المرجح أن تؤثر معالجة رسائل النافذة غير الصحيحة على أمان أنظمة Windows الحديثة لسببين. أولاً ، لا يمكن إرسال رسائل النافذة عبر الشبكة. ثانياً ، تعطل تطبيق أو رمز تنفيذ في نفس مستوى الامتياز ليس مفيدًا جدًا للمهاجمين. ربما ، كان واضحا لمؤلفي تقرير NT المزيف. لا تصدر بيانات أمان ، ولكنها تشير بشكل صحيح إلى أن حالات الفشل في معالجة رسائل النافذة تعني عدم وجود اختبارات صارمة.

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

منهجية الاختبار

لإخفاء جميع التطبيقات في مجموعة الاختبار ، استخدمنا نفس الكود الأساسي وتقنية الدمج الموصوفة في تقرير NT الأولي. على وجه الخصوص ، في كلا وضعي SendMessage و PostMessage ، استخدم fazer ثلاث تكرارات من 500000 رسالة مع 42 بذرة وثلاث تكرارات من 500000 رسالة مع 1337 بذرة. ظهرت النتائج بعد إجراء تكرار واحد فقط لكل طريقة.

لقد فاتنا إدخال الماوس ولوحة المفاتيح بشكل عشوائي بسبب ضيق الوقت والرغبة في التركيز فقط على رسائل النافذة. ونحن نشجع أيضًا أولئك الذين يرغبون في تكرار الاختبار وتأكيد النتائج.

المزالق

ل fuzzer في ويندوز 10 كان لا بد من إجراء تغييرين طفيفين. أولاً ، قم بتكييفه لمنصة 64 بت. التغيير الثاني سمح fuzzer لتحديد مؤشر إطار معين باستخدام وسيطة سطر الأوامر. يعد دمج واصف محدد حلاً سريعًا لتطبيقات تطبيقات Universal Windows Platform (UWP) . يركز البرنامج الأصلي على دمج النوافذ التي تنتمي إلى عملية معينة ، لكن جميع تطبيقات UWP تعرض واجهة المستخدم الخاصة بها من خلال نفس العملية (الشكل 2). هذا يعني أنه لا يمكن توجيه fuzzer إلى نافذة تطبيق UWP الرئيسية.


التين. 2. على نظام UWP ، تنتمي جميع التطبيقات إلى عملية واحدة ( ApplicationFrameHost.exe ). لخلط هذه التطبيقات ، اضطررت إلى تغيير fuzzer الأصلي NT وتوجيهه إلى مقابض نافذة محددة

كان هناك خلل خطير في تعديل fuzzer: القيم المحددة للمصدرين الرئيسيين للإدخال العشوائي ، lParam و wParam لـ SendMessage و PostMessage ، تقتصر على أعداد صحيحة 16 بت. كلا الوسيطتين 32 بت على Windows 32 بت و 64 بت على 64 بت Windows. المشكلة تحدث في Fuzz.cpp ، حيث wParam lParam و wParam :

  wParam = (UINT) rand(); lParam = (LONG) rand(); 

تقوم الدالة rand () بإرجاع رقم في النطاق [0 ، 2 ¹⁶ ] ، مما يحد بشكل كبير من مجموعة القيم المختبرة. لقد قمنا بحفظ هذا الخطأ عن قصد أثناء الاختبار بحيث تتم مطابقة النتائج بدقة مع العمل الأصلي.

تطبيقات اختبار

في تقرير NT الأصلي ، تم اختبار 33 برنامجا. لدينا 28 فقط ، لأنه يتم استخدام إصدار واحد فقط من كل برنامج للاختبار. لقد تغير النظام البيئي لبرنامج Windows بشكل كبير منذ عام 2000 ، على الرغم من أن الكثير من المستغرب لم يتغير. يحتوي مجموعة Microsoft Office على نفس البرامج كما في الاختبارات الأصلية. تطورت Netscape Communicator إلى Firefox. تم تغيير اسم Adobe Acrobat إلى Adobe Reader ، لكنه لا يزال ساري المفعول. أصدرت Winamp إصدارًا جديدًا في عام 2018 ، والذي يسمح بإجراء مقارنة عادلة مع التقرير الأصلي. ومع ذلك ، كان لا بد من استبدال بعض البرامج القديمة. انظر أدناه للحصول على قائمة التغييرات وأسبابها:

• مشغل CD ⇨ Windows Media Player: يتم تضمين وظيفة CD Player في البرنامج الجديد.
  
• بريد Windows Eudora: يتعامل Qualcomm الآن مع الرقائق بدلاً من عملاء البريد الإلكتروني. نظرًا لأن Eudora لم يعد موجودًا ، تم اختبار عميل بريد Windows الافتراضي بدلاً من ذلك.
  
• Command AntiVirus ⇨ Avast Free Edition: لم يعد Command AntiVirus متاحًا. تم استبدال Avast بأكثر برامج مكافحة الفيروسات شيوعًا.
  
• GSView ⇨ الصور: لم يعد GSView مدعومًا. تم استبداله مع عارض الصور الافتراضي في Windows.
  
• JavaWorkshop Net NetBeans IDE: لم يعد JavaWorkshop IDE مدعومًا. يبدو NetBeans كبديل مجاني جيد يطابق روح ما يجب التحقق منه.
  
• Secure CRT ⇨ BitVise SSH: لا يزال Secure CRT موجودًا ، ولكن يلزم وجود نموذج ويب طويل للغاية لتنزيل الإصدار التجريبي. عرضت BitVise SSH تمهيد سريع.
  
• Telnet ⇨ Putty: لا يزال تطبيق telnet موجودًا على Windows ، ولكنه الآن تطبيق وحدة تحكم. لتضمين واجهة المستخدم الرسومية ، استبدلناها بـ Putty ، المحاكي الشهير للمصدر المفتوح لنظام التشغيل Windows.
  
• وجدنا Freecell and Solitaire في مجموعة Microsoft Solitaire من كتالوج تطبيق Windows App Store.

يتم عرض الإصدار المحدد من التطبيق في جدول النتائج. تم تنفيذ كل عمليات الدمج على نظام Windows 10 Pro الإصدار 649 من نظام 64 بت (بناء 17763.253).

النتائج

كما هو مذكور في التقرير الأصلي ، لا ينبغي اعتبار النتائج بمثابة ثغرات أمنية ، ولكن كمؤشر لموثوقية البرامج وجودتها.

"أخيرًا ، تشكل نتائجنا نقطة انطلاق كمية للحكم على التحسن النسبي في موثوقية البرنامج."

- من "الدراسة التجريبية لموثوقية تطبيق Windows NT باستخدام اختبار عشوائي" بقلم جاستن فورستر وبارتون ميلر

الأرقام ليست مشجعة بشكل خاص ، على الرغم من أن الوضع يتحسن. في تقرير NT الأولي ، تعطلت جميع التطبيقات أو علقت على الغموض. الآن برنامجان: الحاسبة و Avast Antivirus ، نجا من مراحل رسائل النافذة دون أي عواقب سلبية. نثني على فريقي Avast و Windows Calculator لنهجهما في رسائل النوافذ الخاطئة. حصل فريق الحاسبة على احترام إضافي لفتح الشفرة المصدرية وإظهار كيفية إنشاء تطبيق UWP عالي الجودة. انظر الجدول 1 للاطلاع على جميع النتائج المزيفة ، بالإضافة إلى الإصدار المحدد من البرنامج المستخدم.

جدول 1. نتائج تشغيل الانصهار الأصلي على Windows 10. بعد 19 عامًا ، ما زالت جميع التطبيقات تقريبًا لا تعالج رسائل النافذة المشوهة بشكل صحيح

علة ويندوز؟

لسوء الحظ ، ساد الفضول ، واضطررنا إلى استثناء واحد. يبدو أن العديد من التطبيقات التي لا صلة لها بالمشكلة قد واجهتها مشكلة واحدة مشتركة. أظهر التصحيح أن المشكلة تتعلق برسالة WM_DEVICECHANGE . عندما أرسل fuzzer هذه الرسالة ، سقط التطبيق أبسط - HelloWorld ، المثال الرسمي لواجهة برمجة تطبيقات Windows (الشكل 3).


التين. 3. تعطل HelloWorld.exe 32 بت عند تلقي رسالة نافذة من fuzzer. لا ينبغي أن يحدث هذا ، لأن البرنامج بسيط تمامًا. ومن المعلوم أن المشكلة في مكان ما في ويندوز

بعد سقوط HelloWorld ، أدركنا على الفور أن المشكلة تؤثر على تطبيقات 32 بت فقط ، ولكن ليس على تطبيقات 64 بت. أظهرت بعض التصحيح السريع أن التعطل يحدث في wow64win.dll ، طبقة توافق التطبيقات 32 بت لـ 64 بت . يؤدي تحليلي السطحي (وربما غير الصحيح) للمشكلة إلى استنتاج مفاده أن الدالة wow64win.dll!whcbfnINDEVICECHANGE تعتبر wParam بمثابة مؤشر إلى بنية DEV_BROADCAST_HANDLE64 في البرنامج الهدف. تحول الوظيفة هذه البنية إلى بنية DEV_BROADCAST_HANDLE32 للتوافق مع تطبيقات 32 بت. يحدث الفشل لأن قيمة wParam التي تم إنشاؤها بواسطة fuzzer تشير إلى ذاكرة غير صالحة.

تعتبر معاملة wParam كمؤشر محلي فكرة سيئة ، على الرغم من أنه قد يكون قرار تصميم متعمد لإعلامات الجهاز القابل للإزالة للعمل مع تطبيقات Windows 32 بت القديمة. ولكن لا يزال من الخطأ أن تتمكن من تعطل تطبيق آخر دون أي مشاكل. أبلغنا MSRC عن المشكلة ، على الرغم من أن الحدود الأمنية لم تعبر. وأكدوا أن الخطأ لم يكن مشكلة أمنية. نأمل أن نرى إصلاحًا لهذه المشكلة الغريبة المقبولة عمومًا في إصدار مستقبلي من Windows.

استنتاج

يتم التقليل من أهمية رسائل النافذة وغالبًا ما يتم تجاهلها باعتبارها مدخلات غير موثوق بها لبرامج Windows. حتى بعد مرور 19 عامًا على ظهور أول رسالة من رسائل مفتوحة المصدر ، ما زال 93٪ من التطبيقات التي تم اختبارها تتجمد أو تتعطل عند بدء تشغيل البرنامج نفسه. لكن من المشجع أن بعض التطبيقات تتعامل بأمان مع هذه المدخلات المشوهة: وهذا يعني أن بعض المنظمات لديها أطر ومعرفة مؤسسية لتجنب مثل هذه الأخطاء.

بالطبع ، يمكن تحسين fuzzer بعدة طرق ، ولكن حتى أبسط الطرق تحطمت 93٪ من التطبيقات. ربما في بعض الحالات ، تعبر رسائل النافذة عن الحدود الأمنية الحقيقية. إذا كنت تستكشف هذا المجال ، نأمل أن تشارك النتائج.