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

تجنب الأخطاء ؛
التقليل من مخاطر الأخطاء.

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

للتوضيح ، لم أختار الكل ، ولكن فقط بعض الأخطاء المثيرة للاهتمام التي تتطابق بطريق الخطأ مع موضوع محادثتنا.

المصادقة libc

تقوم وظائف المصادقة بتشغيل المساعدين بدون التحقق من الأمر. تقرير . التصحيح .

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

جزء أكثر إثارة للاهتمام من القصة هو أنه حتى مع خطأ libc المذكور ، وظيفة login_passwdلن أكون ضعيفًا بهذه الطريقة إذا لم يكن هناك خطأ آخر. في عام 2001 ، تمت إعادة كتابة login_passwd لدعم kerberos ، وربما حدث ذلك عندما قدموا السبب الحقيقي للخطأ. يعرض عرض مصادقة نوع طلب الاستجابة (كما هو الحال في نظام s / key) حالة مصادقة ، وليس صمتًا. بعد سنوات عديدة ، تم حذف رمز kerberos ، ولكن بقي جزء من الرمز لدعمه ، بالإضافة إلى الخطأ المقدم.

إذا تم تنظيف كود kerberos تمامًا ، فسيظل خطأ المصادقة موجودًا (كانت هناك بعض المشاكل الأخرى ذات الصلة بتحليل argv) ، ولكن من المؤكد أن تأثيره سينخفض بشكل كبير.

ليس من السهل تحليل argv بشكل صحيح في سياق الأمان. العديد من النصائح والأساليب المنطقية لا تعمل هنا. سألاحظ فقط أن هذه الثغرة ظهرت بعد ذلكمناقشة أخرى للمشكلة مع أسماء الملفات على Unix / Linux / POSIX ، على الرغم من أن السالب (الواصلة) لا يشير حقًا إلى اسم الملف.

ld.so

لم تتم إزالة متغيرات البيئة السيئة من رمز ld.so. تقرير . التصحيح .

شيء مثل خطأ في الذاكرة. لكن لا. الخطأ هنا هو ربط نجاح عملية واحدة - تقسيم متغير البيئة - لحذف هذا المتغير. واثق جدا.

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

بروتوكول نقل الملفات

بروتوكول نقل الملفات يتبع عمليات إعادة التوجيه إلى الملفات المحلية. تقرير . التصحيح .

لطالما كان خطأ إعادة توجيه NetBSD ftp مثالاً نموذجيًا على الوظائف غير المنضبط . وهنا مرة أخرى نفس الخطأ (لحسن الحظ ، مع عواقب طفيفة)! الرجال ، حسنا ، الجلوس في المنزل. لا تضيف ميزات إضافية لبرامجك.

smtpd من

لا يمكن لـ smtpd التحقق من بعض عناوين المرسل. تقرير . التصحيح . تعليق .

أعتقد أن كل شيء قيل في شرح جيل ، لكني سأذكر الخلفية. ذات مرة ، تم تخزين كل البريد محليًا لكل مستخدم في / var / mailفي ملفات mbox. هذا ليس رائعًا جدًا ، لأن هناك فرصة للضرر إذا قامت mua بحذف البريد الإلكتروني بينما تسلم mda رسالة جديدة (ناهيك عن مشاكل أخرى مثل تشويه الحقل من). لذلك ، يجب تأمين ملف mbox. لكن قفل نظام ملفات الشبكة لا يعمل بشكل موثوق. لذا بدلاً من القفل نستخدم ملفات القفل. ومع ذلك ، تحتاج إلى التوصل إلى اتفاق بشأن بروتوكول حظر معين ، لأن المستخدم يمتلك ملفات mbox ، والجذر نفسه يمتلك الدليل. وبالتالي ، من أجل تعديل ملف mbox فعليًا ، تحتاج إلى تشغيل وظيفة المساعد setuid في كل مرة. حسنا ، هذه هي المشكلة الأولى. بقايا أخرى من الأيام الخوالي هي إعدادات mda ، والتي يمكن استخدامها ليس فقط كبرنامج ، ولكن كخط أنابيب قذيفة. يصف الناس شيء مثلspam-assassin | mail.mdaولا يمكنك تمريرها فقط execve().

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

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

قراءة smtpd

يمكن استخدام القراءة خارج النطاق في smtpd لتنفيذ الأوامر. تقرير . التصحيح .

هذه حقًا مشكلة أمان في الذاكرة. من خلال إرسال بعض أشرطة الحالة المضحكة ، يمكن لخادم smtp البعيد إدخال أوامر في قائمة انتظار smtpd للتنفيذ. عندما يتم وضع رسالة بريد إلكتروني في قائمة الانتظار لإعادة التسليم ، يضيف smtpd بعض معلومات الوجهة إلى الرأس لمعرفة الأمر المطلوب تنفيذه (انظر أعلاه). يشبه هذا الهجوم "تهريب" طلبات http . إذا كان بإمكانك إنشاء "shit" بأوامر غير متوقعة في الرأس ، فسيقوم smtpd بتنفيذها عند محاولة إعادة التسليم.

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

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

الموجودات

بالطبع ، كان الاستنتاج واضحًا منذ البداية ، لكننا سنتحدث عنه على أي حال.

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

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

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

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

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

كتابة خادم البريد هو عمل صعب. خاصة إذا كانت الإطارات القديمة تشدك.

حان الوقت لإعادة التفكير في أمان OpenBSD