zanezhub/cve-2022-1015-1016ترجمة إلى الإسبانية للثغرات CVE-2022-1015 وCVE-2022-1016 التي اكتشفها ووثّقها David.
ملف README.md هذا هو ترجمة لـمدونة ديفيد. وجد ديفيد الثغرتين 1015 و1016 من فئة CVE في نواة لينكس. يمكنك زيارة موقعه على الويب لقراءة المستند الأصلي.
إليك حساباته على وسائل التواصل الاجتماعي:
نُشر في 2 أبريل 2022.
يُفترض أن تكون هذه المشكلات قابلة للاستغلال في الإعدادات الافتراضية لأحدث إصدار من Ubuntu وRHEL. كتبتُ إثبات المفهوم (PoC) الخاص بي لـ CVE-2022-1015 مستهدفًا إصدار النواة 5.16-rc3 من Arch Linux.
هذا المستند موجّه للأشخاص الذين لديهم معرفة أساسية بنواة لينكس من حيث الوظيفة والأمان. حاولت جعل هذا المستند سهلًا للأشخاص الذين يفتقرون إلى المعرفة بمكدس الشبكات (network stack) ليكون في متناول الجميع.
إليك دليل قراءة:
في منتصف فبراير، أعلن برنامج الأمان من Google أنهم سيواصلون برنامج مكافآت kCTF، حيث يقدمون مكافآت تتراوح من 31,337 دولارًا حتى 91,337 دولارًا مقابل استغلال (exploit) في نواة لينكس يمكنه رفع الامتيازات إلى المستخدم root من عمليات بدون امتيازات داخل صندوق عزل nsjail.
باعتباري طالبًا فقيرًا، من الواضح أن هذا لفت انتباهي. كانت هذه أول مرة أبحث فيها عن ثغرة من "العالم الحقيقي"، لكنني في مغامراتي في لعب CTF مع فريقي، أصبحت على دراية بنواة لينكس من حيث الأمان. بعد ساعات وساعات مع تقدم لا يكاد يذكر (ولكن بمعرفة أكبر عن لينكس) تمكنت من العثور على بعض الثغرات في وحدة nf_tables.
للأسف، في نهاية المطاف، أدركت أن هذه الوحدة لم تكن ضمن قواعد kCTF من Google (لذا لم أحصل على أي مكافأة عن هاتين الثغرتين). لكن بوضوح، ما زلت أبلغت عنهما وكتبت استغلال LPE (رفع امتيازات محلي) لـ CVE-2022-1015.
حسنًا، لقد قررت أنك ستجد بعض الثغرات في لينكس. ماذا الآن؟ لينكس مشروع ضخم، ومن السهل جدًا ألا ترى الغابة بسبب الأشجار (تركز كثيرًا على التفاصيل لدرجة أنك تفقد رؤية ما هو مهم حقًا، ولا تملك نظرة عامة على الموقف). ولزيادة الطين بلة، العديد من الأجزاء غير موثقة وتحتاج إلى قراءة قدر كبير من الكود لفهم ما يحدث.
بدأت بمحاولة تكوين منظور مفصل لنموذج أمان لينكس. العثور على خلل (bug) شيء؛ لكن العثور على خلل جيد شيء آخر مختلف تمامًا. ففي النهاية، ليست كل الخلل (bugs) متساوية:
FS_USERNS_MOUNT، وفي هذه الحالة يمكنك تركيبها داخل user namespace.CAP_SYS_ADMIN أو CAP_NET_ADMIN.
/proc/config.gz. يمكن تحميل الوحدات (=m) أو تجميعها منفصلة وتحميلها في وقت التشغيل (=y)./proc/modules و/proc/kallsyms، لكنهما ليسا موثوقين دائمًا، إذ يمكن تحميل الوحدات ديناميكيًا في النواة (مثلًا request_module).تساعدنا هذه القيود في معرفة حدود الأنظمة التي يمكننا البحث فيها عن الثغرات. أعتقد أنها فكرة جيدة أن تأخذ وقتك في محاولة تخطيط هجومك على الهدف الذي ترغب به.
لقد تعلمت الدرس بالفعل بشأن النقطة السابقة. كما ذكرت، لم تكن وحدة nf_tables محمّلة في المثيل الذي طرحته لنا kCTF. كان بإمكاني ملاحظة ذلك منذ البداية وأوفر على نفسي خيبة الأمل :p. من ناحية أخرى، ربما لم تكن تقرأ هذه المدونة الآن لو كنت قد انتبهت لذلك مبكرًا، أظن أن الأمور سارت على ما يرام في النهاية.
يمكن العثور على تفسير لسبب عدم احتواء COS، فرع لينكس المُحسَّن للحاويات من Google، على nf_tables هنا وهنا.
بعد تقييم النقاط المذكورة سابقًا، قررت أن أفضل طريق لي للبدء ربما يكون الاطلاع على الكود المصدري للشبكة. العديد من الوظائف المثيرة للاهتمام هناك تتطلب CAP_NET_ADMIN، لكن كما ذكرت، هذه ليست مشكلة في الواقع. على العكس، أشك في أن المكونات التي تتطلب قدرات خاصة تكون عمومًا أقل أمانًا، لأن مطوري النواة قد تكون لديهم إحساس زائف بالأمان.
كما بذلت جهدًا لاختيار النظام الذي أردت معرفة المزيد عنه؛ وبهذه الطريقة، حتى لو لم تجد أي خلل، فستتعلم مع ذلك الكثير من الأشياء المثيرة للاهتمام.
حققت في العديد من الأنظمة الفرعية للشبكة، لكنني لم أعثر على أي شيء مهم. بعد تصفح الدليل الفرعي net/، صادفت وحدة nf_tables. بدت معقدة بعض الشيء، لذا قررت أن آخذ بعض الوقت للتعرف عليها.
netfilter (net/netfilter) هو نظام فرعي شبكي كبير جدًا في النواة. باختصار، يضع netfilter خطافات (hooks) عبر وحدات الشبكة حيث يمكن للوحدات الأخرى تسجيل معالجات (handlers) لها. عند بلوغ خطاف (hook)، يُفوَّض التحكم إلى تلك المعالجات، ويمكنها التعامل مع بنية حزمة الشبكة المعنية. يمكن للمعالجات قبول الحزم أو إسقاطها أو تعديلها.
بعد ساعات قليلة من تصفح واجهة برمجة تطبيقات nf_tables (net/netfilter/nf_tables_api.c) لمعرفة طريقة عملها بدقة، قررت إلقاء نظرة على التحقق المنطقي من السجلات التي يرسلها المستخدم، ووجدت بعض السلوكيات المثيرة للريبة. بعد التفكير فيما إذا كنت أفقد صوابي أم لا، كتبت PoC صغيرًا (إثبات مفهوم) لمحاولة تشغيل الثغرة التي وجدتها: ثغرة تُعرف باسم OOB أو خارج الحدود، وتتيح القراءة والكتابة في ذاكرة المكدس (stack).
بعد إيجاد طريقة لتسريب عناوين النواة، كان التحكم في مؤشر الذاكرة أمرًا سهلاً إلى حد كبير. وبعد القليل من ROP (البرمجة الموجهة بالإرجاع)، أصبحت shell بامتيازات root حقيقة واقعة.
كلما احتاج روتين init لتعبير إلى تحليل سجل من رسالة مستخدم في netlink، يتم استدعاء روتين nft_parse_register_load أو روتين nft_parse_register_store اعتمادًا على ما إذا كان السجل مصدريًا أو وجهة. أضفت بعض التعليقات:```c
int nft_parse_register_load(const struct nlattr *attr, u8 *sreg, u32 len)
{