IMChecker
1.0.0
Thu ، مجموعة Imchecker ، اتصل بنا على [email protected]
تقدم المكتبات وظائف قابلة لإعادة الاستخدام من خلال واجهات برمجة التطبيقات (APIs) مع قيود الاستخدام ، مثل شروط الاتصال أو الطلبات. انتهاكات القيد ، أي أسياد API ، تؤدي عادة إلى الحشرات وقضايا الأمن. على الرغم من أن الباحثين قاموا بتطوير مختلف أجهزة الكشف عن واجهة برمجة التطبيقات في العقود القليلة الماضية ، إلا أن الدراسات الحديثة تشير إلى أن سوء استخدام API ينتشر في مشاريع العالم الحقيقي. تعاني النهج الحالية إما من مشكلة الاستخدام المتفرقة (أي ، الأخطاء التي نادراً ما تحدث) أو الإبلاغ عن أجهزة إنذار كاذبة بسبب الدلالات غير الدقيقة. للتغلب على هذه القيود ، نقدم Imchecker لاكتشاف أخطاء واجهة برمجة التطبيقات بشكل فعال. البصيرة الرئيسية وراء Imchecker هي تقنية تحليل ثابت موجهة للقيود مدعوم من لغة خاصة بالمجال (DSL) لتحديد قيود استخدام API. من خلال دراسة الأخطاء الواقعة API-Misuse ، نقترح IMSPEC DSL ، والتي تغطي غالبية أنواع قيود استخدام API وتتيح مواصفات بسيطة ولكنها دقيقة. علاوة على ذلك ، نقوم بتصميم وتنفيذ imchecker لتحليل IMSPEC تلقائيًا في التحقق من الأهداف وتوظيف محرك تحليل ثابت لتحديد سوء استخدام واجهة برمجة التطبيقات (API) المحتملة وتكبير الإيجابيات الخاطئة مع دلالات غنية. لقد قمنا بتثبيت Imchecker لبرامج C وتقييمها على المعايير المستخدمة على نطاق واسع وبرامج العالم الحقيقي على نطاق واسع.
حاليًا ، تم العثور على 75 من الأخطاء غير المعروفة سابقًا وتم تأكيد 61 وتثبيتها في Linux kernel ، و OpenSSL والحزم في Ubuntu 16.04. نحن نبذل قصارى جهدنا لتطبيق Imchecker على المزيد من البرامج. نقوم بتحميل التفاصيل في التقييم _data/new_bugs
مخطوطة الأبحاث الخاصة بنا ومخطوطات الأدوات قيد المراجعة لـ ICSE'19. سنقوم بتحميلها بمجرد الانتهاء من عملية المراجعة. (حسنًا ، يمكنك مراسلتنا عبر البريد الإلكتروني للوصول إليها عن طريق الغرض الأكاديمي فقط.)
يتوفر فيديو عرض الأدوات الخاص بنا في الإصدار الإنجليزي: https://youtu.be/ygdxeyoevim النسخة الصينية:
استخدام أدواتنا في الأدوات/readme.md
لا يزال Imchecker قيد التطوير ، ويحتوي على الكثير من القوائم وقوائم TODO. أي أخطاء أو طلبات ميزة ، لا تتردد في مراسلتنا عبر البريد الإلكتروني على [email protected] أو القضايا المفتوحة.
لفهم أفضل نوع من الأخطاء المميتة التي تحدث في مشاريع C الحقيقية وكيف يقوم المطورون بإصلاحها في الممارسة العملية ، درسنا يدويًا تاريخ إصدار لمدة عامين لثلاثة مشاريع مفتوحة المصدر وسنة واحدة من Linux-Kernel في عام 2017 ، كما هو موضح في الجدول التالي. يتم اختيار هذه التاريخ بسبب التطور المستمر ولأنها يتم ذكرها بشكل متكرر في أعمال الكشف عن الأخطاء المتنوعة. في المجموع ، درسنا حوالي 13.57 مليون موقع و 51.1K.
| مشروع | لوك | الفترة التي شملتها الدراسة | إجمالي الالتزامات | إصلاحات الأخطاء | API يسيء استخدام |
|---|---|---|---|---|---|
| حليقة | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| gnutls | 35.8k | 20160101-20171231 | 2769 | 86 | 30 |
| OpenSSL | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12.96 م | 20170701-20171231 | 39295 | 995 | 362 |
| المجموع | 15.57 م | عامين | 51.1K | 1560 | 509 |
لمساعدة القراء على استخراج رسالة الالتزامات والملفات وملفات التصحيح ، نفتح مصدر أداة GitGrabber الخاصة بنا. نقوم أيضًا بتحميل جميع الالتزامات المتعلقة بأخطاء واجهة برمجة التطبيقات (API) في الموضوعات المدروسة لمزيد من الاستخدام.
يمكن للقراء العثور عليها في مجلد تجريبي. أي مشاكل على gitgrabber ، لا تتردد في الاتصال بنا!
نختار معيارًا مستخدمًا على نطاق واسع ، IE ، Juliet Test Suite v1.3 ، وبرنامجين في العالم الحقيقي في أحدث إصداراتهما: Linux kernel-4.18-RC4 صدرت في 2018-7-9 و Openssl-1-1-PRE8 تم إصدارها في 2018-6-20 لتقييم مقاربتنا. نقوم بتقييم نهجنا من منظورين.
نختبر أيضًا هذه الحالات على Apisan أداة للكشف عن استخدام API من خلال التحقق المتقاطع الدلالي و Clang-SA أداة تحليل ثابت مفتوحة المصدر.
نقوم بتحميل المرتبة الوسيطة api-misuse والنتائج الأصلية في التقييم.
يتمثل الدافع الرئيسي لـ Imchecker في الكشف عن حشرات API-Misuse في برامج العالم الحقيقي ، وهي تحديد ما إذا كان بإمكان Imchecker العثور على الأخطاء غير المعروفة مسبقًا. لذلك ، نطبق Imchecker على أحدث إصدارات من برنامجين معروفين مفتوح المصدر: Linux kernel-4.18-RC4 و OpenSSL-1-1-1-PRE8 ، والحزم في Ubuntu 16.04. يتم اختيار واجهات برمجة التطبيقات المستهدفة من تلك الخاطئة من الدراسة التجريبية.
حتى الآن ، تم العثور على 56 حشرات غير معروفة من قبل وتم تأكيد 36 من قبل المطورين.
| مشروع | الأخطاء (استجابة الانتظار/تأكيد/ثابت) |
|---|---|
| OpenSSL | 17 (0/5/12) |
| Linux | 30 (5/20/5) |
| DMA | 1 (0/0/1) |
| exim | 2 (0/0/2) |
| Hexchat | 2 (1/1/0) |
| httping | 1 (0/1/0) |
| ipmitool | 1 (0/1/0) |
| أدوات مفتوحة VM | 2 (0/0/2) |
| IRSSI | 2 (1/1/0) |
| Keepalive | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| Freeradius-server | 2 (0/0/2) |
| Trafficserver | 3 (3/0/0) |
| tinc | 2 (0/0/2) |
| SSLPlit | 2 (0/0/2) |
| rdesktop | 2 (2/0/0) |
| بروكسي تونيل | 2 (2/0/0) |
| المجموع | 75 (16/29/32) |
نقوم بتحميل التفاصيل في التقييم _data/new_bugs
لقد تبين أن المواصفات السلوكية التي تصف قيود استخدام API مفيدة للمطورين لاستخدام واجهات برمجة التطبيقات بشكل فعال وكذلك لمواجهة مشكلة الاستخدام المتفرقة من خلال ضمان التحقق من استخدامات واجهات برمجة التطبيقات المستهدفة. على سبيل المثال ، يقدم Bodden CRYSL لسد الفجوة المعرفية بين خبراء التشفير والمطورين. ومع ذلك ، يتم تصميم لغات المواصفات الحالية إما لخصائص البرنامج الكاملة ، مثل BLAST أو JML أو محددة للغاية بحيث لا يمكن تطبيقها على اكتشاف استخدام API العام ، مثل SLIC. نقدم لغة محددة للمجال خفيفة الوزن لقيود استخدام API المسمى IMSPEC. يضمن IMSPEC في وقت واحد أن يتم التحقق من صحة واجهات برمجة التطبيقات المستهدفة ، حتى مع وجود عدد قليل من الاستخدامات ، ويرشد الكشف عن سوء الاستخدام. مثيل IMSPEC هو نمط مليء بمجموعة من القيود لاستخدام واجهة برمجة التطبيقات بشكل صحيح ، وسيؤدي أي انتهاك إلى خلل في واجهة برمجة التطبيقات.
نقوم بتحميل مثيلات IMSPEC إلى مجلد IMPSEC ، سنقوم بتحديث هذا المجلد بشكل تدريجي لمزيد من واجهات برمجة التطبيقات. علاوة على ذلك ، يمكن استخدام IMSPEC لغرض آخر ، مثل إنشاء حالات اختبار ، والتحقق وما إلى ذلك. علاوة على ذلك ، نحن نقدم كاتب واجهة المستخدم الرسومية IMSPEC في الأدوات.
حاليًا ، يتم إنشاء iMspec بواسطة الكتابة اليدوية. ومع ذلك ، فإننا نتأكد من أنه يمكن إنشاؤه تلقائيًا من تقنيات التعدين المواصفات. نحن نبذل قصارى جهدنا لإجراء التجارب وتنفيذ المحللين لترجمة النتائج من أدوات التعدين إلى IMSPEC ، مثل Apex. لكن هذه الأدوات لا يمكنها حل جميع قيود الاستخدام. نود أيضًا دعوة المطورين لمساعدتنا في تحسين مثيلات IMSPEC التي تم إنشاؤها وفقًا لدليل المستخدم ، مثل OpenSSL.
يجب أن تفي مستخدم API الصحيح بمجموعة من قيود الاستخدام ، أي أن انتهاكات القيود قد تؤدي إلى حشرات API-Misuse. يكتشف Imchecker تلقائيًا هذه الأخطاء في رمز المصدر باستخدام مواصفات IMSPEC. لمعالجة البرامج المعقدة والواقعية ، يجب أن تكون آليات Imchecker الأساسية قابلة للتطوير مع التضحية بالحد الأدنى من الدقة. نحن نوضح تفاصيل التصميم الخاصة بـ Imchecker ، بما في ذلك التنفيذ الرمزي غير المقيد مع تقنيات التحليل الثابت لإنشاء سياق التحليل ، ومنهجيات اكتشاف أخطاء واجهة برمجة التطبيقات (API) في سياق التحليل وطريقة لتصفية الإيجابيات الخاطئة باستخدام المعلومات الدلالية وإحصائيات الاستخدام.
نستخدم مثالًا محفزًا لتوضيح سير عمل Imchecker. هذا خطأ في API-Misuse في OpenSSL المبلغ عنه في CVE-2015-0288. أدى التحقق من رمز الخطأ المفقود لـ X509_get_pubkey() إلى خلل دسم مؤشر فارغ في السطر 4.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }ها هو سير العمل من Imchecker:
يأخذ Imchecker قيود الكود المصدر و API كقيود استخدام كإدخال وإنشاء تقارير الأخطاء مع مواقع ملموسة وأسباب الإخراج. أولاً ، تتم كتابة قيود استخدام واجهة برمجة التطبيقات بلغة خفيفة الوزن خاصة بالمجال المسماة IMSPEC ؛ على سبيل المثال ، "يجب التحقق من قيمة إرجاع X509_GET_PUBKEY () مع NULL" . من خلال توظيف هذه المواصفات ، يقوم Imchecker بصحة مباشرة باستخدام واجهة برمجة التطبيقات المستهدفة ، والتي تخفف من مشكلة الاستخدام المتفرقة وتوجه عملية اكتشاف الأخطاء. بعد ذلك ، نكتشف الحشرات api-misuse في ثلاث مراحل. (1) في المرحلة الأولى ، تم تصميم سياق التحليل عن طريق إنشاء رسم بياني لتدفق التحكم وإنشاء آثار مسار البرنامج لكل واجهة برمجة تطبيقات مستهدفة محددة في المواصفات من خلال استخدام التنفيذ الرمزي غير المقيد مع التحليل الحساس للمسار والمسار. في هذا المثال ، يتم إنشاء تتبعان ، T1 و T2 ، كما هو موضح في المربع أعلاه آثار مسار البرنامج. وبهذه الطريقة ، يمكن لـ Imchecker التقاط سياق استخدام X509_get_pubkey() و EVP_PKEY_free() وتلك الموجودة بينهما. (2) في المرحلة الثانية ، يستخدم Imchecker آثار الكشف عن انتهاكات القيود مثل الأخطاء المحتملة. Forexample ، تم العثور على مثيلات twoapi-misuse من X509_get_pubkey() لفحص رمز الخطأ المفقود المسمى على أنها الأخطاء المحتملة. (3) في المرحلة 3 ، يحسن Imchecker دقة الكشف عن طريق الاستفادة من مثيلات الاستخدام المتعددة والمعلومات الدلالية. بعد ذلك ، يتم ترشيح سوء الاستخدام الثاني للشيك الذي تم إجراؤه في X509_to_X509_REQ() في السطر 25.
يمكن العثور على استخدام أدنا هنا: الأدوات/README.MD
أثناء التحقيق في تقارير الأخطاء التي تم إنشاؤها بواسطة Imchecker ، نجد العديد من الأخطاء المثيرة للاهتمام واكتساب خبرة مفيدة في عملية الإبلاغ عن الأخطاء مع مطوري المصدر المفتوح. نشارك تجربتنا التالية.
يود المؤلفون أن يشكروا مطوري Linux kernel و OpensSL لمساعدتنا على تحسين IMSPEC وتأكيد تقارير الأخطاء.
