كيفية تأمين C



لغة C قوية جدًا ويتم استخدامها كثيرًا - خاصة في نواة Linux - ولكنها أيضًا خطيرة جدًا. وصف أحد مطوري نواة Linux كيفية التعامل مع الثغرات الأمنية C.

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

بالإضافة إلى المزالق مثل الأسماء المستعارة للمؤشر ، فإن لغة C لديها أخطاء أساسية غير مصححة تنتظر ضحاياها. هذه هي الثغرات الأمنية التي عالجها Case Cook ، مهندس أمان نواة Google Linux في مؤتمر أمان Linux في فانكوفر.

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

إذا كنت تستخدم C في مشاريعك ، فيجب الانتباه إلى المشكلات الأمنية.

حماية نواة لينكس


بمرور الوقت ، اكتشف كوك وزملاؤه العديد من المشاكل مع C. الأصلي لمعالجتها ، تم إطلاق مشروع Kernel للحماية الذاتية . يعمل ببطء وثبات لحماية نواة لينكس من الهجمات ، وإزالة الكود الإشكالي من هناك.

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

مع مثل هذا الحمل ومع المكتبات القياسية الضعيفة في C ، هناك الكثير من السلوك الغامض. استشهد كوك - ووافق - مع مقالة مدونة راف ليفين ، "مع السلوك غير المحدد ، كل شيء ممكن . "

قدم كوك أمثلة محددة: "ما هو محتوى المتغيرات" غير المهيأة "؟ هذا كل ما كان في ذاكرتي من قبل! لا توجد أنواع في مؤشرات الفراغ ، ولكن هل يمكن استدعاء الوظائف المكتوبة من خلالهم؟ بالطبع! التجمع هو نفسه: يمكنك الاتصال بأي عنوان! لماذا لا تحتوي memcpy() على الوسيطة "الحد الأقصى لطول الوجهة"؟ لا يهم ، فقط افعل ما تقول. كل مناطق الذاكرة متشابهة! "

تجاهل التحذيرات ... ولكن ليس دائمًا


يسهل التعامل مع بعض هذه الميزات نسبيًا. وعلق كوك: "يحب لينوس [Torvalds] فكرة تهيئة المتغيرات المحلية دائمًا. لذا قم بذلك فقط. "

ولكن مع تحفظ. إذا قمت بتهيئة متغير محلي في المحول ، فسوف تتلقى تحذيرًا: "لن يتم تنفيذ العبارة مطلقًا [-Wswitch-unreachable] " نظرًا للطريقة التي يعالج بها المترجم الشفرة. يمكن تجاهل هذا التحذير.

ولكن لا يمكن تجاهل جميع التحذيرات. قال كوك "المصفوفات ذات الطول المتغير دائما سيئة". تتضمن المشكلات الأخرى استنفاد المكدس وتجاوز السطر وانتهاكات حماية الصفحة. بالإضافة إلى ذلك ، لفت كوك الانتباه إلى بطء VLA . أدت إزالة جميع VLAs من النواة إلى زيادة الأداء بنسبة 13٪. تحسين السرعة والأمان على حد سواء فائدة مزدوجة.

على الرغم من إزالة VLAs تقريبًا من النواة ، إلا أنها لا تزال في بعض الشفرات. لحسن الحظ ، من السهل العثور على -Wvla باستخدام -Wvla مترجم -Wvla .

هناك مشكلة أخرى مخفية في دلالات C. إذا كان الاستراحة مفقودة في المفتاح ، فماذا يعني المبرمج؟ فاصل التخطي يمكن أن يؤدي إلى تنفيذ التعليمات البرمجية من عدة شروط ؛ هذه مشكلة معروفة.

إذا كنت تبحث عن عبارات فاصل / مفتاح في التعليمات البرمجية الحالية ، يمكنك استخدام -Wimplicit-fallthrough لإضافة عبارة تبديل جديدة. هذا في الواقع تعليق ، لكن المترجمين الحديثين يحللونه. يمكنك أيضًا وضع علامة واضحة على عدم وجود استراحة من خلال تعليق "خارق" .

كما وجد Cook نتيجة أداء عند فحص الحدود لتخصيص ذاكرة البلاطة . على سبيل المثال ، يؤدي التحقق من strcpy()-family تقليل الأداء بنسبة 2٪. البدائل مثل strncpy() مشاكلها الخاصة. تبين أن Strncpy لا ينتهي دائمًا بحرف فارغ. للأسف خاطب كوك الجمهور: "أين يمكنني الحصول على أفضل واجهات برمجة التطبيقات؟"

خلال إحدى جلسات الأسئلة والأجوبة ، سأل أحد مطوري لينكس ، "هل يمكنني التخلص من واجهات برمجة التطبيقات القديمة السيئة؟" رد كوك بأن لينكس دعم مفهوم واجهات برمجة التطبيقات القديمة لبعض الوقت. ومع ذلك ، رفض Torvalds هذه الفكرة ، بحجة أنه إذا كانت أي واجهة برمجة تطبيقات قديمة ، فيجب التخلص منها تمامًا. وأضاف كوك ، ومع ذلك ، فإن إسقاط واجهة برمجة التطبيقات إلى الأبد "أمر خطير سياسيًا". لذلك بينما نحن عالقون.

حل طويل الأمد للمشكلة؟ المزيد من المطورين فهم قضايا الأمن


يتوقع كوك رحلة طويلة وصعبة. بدت فكرة إنشاء لهجة Linux C ذات مرة جذابة ، لكنها لن تفعل ذلك. وقال إن المشكلة الحقيقية في الشفرة الخطيرة هي أن "الناس لا يريدون القيام بتنظيف الشفرة - ليس فقط الشفرة السيئة ، ولكن سي نفسها". كما هو الحال مع جميع المشاريع مفتوحة المصدر ، "نحن بحاجة إلى المزيد من المطورين والمراجعين والمختبرين والمتخصصين في مجال الطباعة الخلفية".

خطر ج: الدروس


  • لغة C لغة ناضجة وقوية ، لكنها تخلق صعوبات فنية ومشكلات أمنية.
  • يولي مطورو Linux اهتمامًا خاصًا لتأمين C (بدون فقدان قوتها) ، لأن معظم نظام التشغيل مكتوب عليه.
  • حدد مهندس أمان Linux Linux kernel ثغرات لغوية محددة وشرح كيفية تجنبها.

Source: https://habr.com/ru/post/ar422623/


All Articles