حددت شركة Qualys الثغرة الأمنية الحرجة الثالثة هذا العام (CVE-2022-3328) في snap-confine، وهي أداة مساعدة مزودة بعلامة جذر SUID، وتُستدعى بواسطة عملية snapd لإنشاء بيئة قابلة للتنفيذ للتطبيقات الموزعة في حزم snap مستقلة. تسمح هذه الثغرة لمستخدم محلي غير مخول بتنفيذ التعليمات البرمجية بصلاحيات الجذر في إعدادات Ubuntu الافتراضية. تم إصلاح المشكلة في إصدار snapd 2.57.6. كما تم إصدار تحديثات للحزمة لجميع فروع Ubuntu المدعومة.
من المثير للاهتمام أن الثغرة الأمنية المعنية ظهرت أثناء إصلاح ثغرة أمنية مماثلة في فبراير في snap-confine. تمكّن الباحثون من إعداد ثغرة فعّالة تُتيح الوصول إلى الجذر لخادم Ubuntu Server 22.04، والتي، بالإضافة إلى ثغرة snap-confine، تستخدم أيضًا ثغرتين أمنيتين في عملية multipathd (CVE-2022-41974 وCVE-2022-41973)، تتعلقان بتجاوز عمليات التحقق من الصلاحية عند تمرير أوامر ذات امتيازات والتعامل غير الآمن مع الروابط الرمزية.
تنشأ الثغرة الأمنية في snap-confine بسبب حالة تسابق في دالة must_mkdir_and_open_with_perms()، والتي أُضيفت للحماية من استبدال دليل /tmp/snap.$SNAP_NAME برابط رمزي بعد التحقق من المالك، ولكن قبل استدعاء استدعاء نظام التثبيت لربط أدلة التثبيت لحزمة snap به. وتتمثل الحماية المضافة في إعادة تسمية دليل /tmp/snap.$SNAP_NAME إلى دليل آخر في /tmp باسم عشوائي إذا كان موجودًا ولم يكن مملوكًا للمستخدم الجذر.
باستغلال عملية إعادة تسمية /tmp/snap.$SNAP_NAME، استفاد الباحثون من كون snap-confine يُنشئ أيضًا مجلد /tmp/snap.rootfs_XXXXXX لجذر محتويات حزمة snap. يتم اختيار الجزء "XXXXXX" من الاسم عشوائيًا باستخدام mkdtemp()، ولكن يمكن للحزمة المسماة "rootfs_XXXXXX" تمرير دالة sc_instance_name_validate (أي أن الفكرة هي أن يكون $SNAP_NAME هو "rootfs_XXXXXX" بحيث تُستبدل عملية إعادة التسمية مجلد /tmp/snap.rootfs_XXXXXX بجذر snap).
لتحقيق الاستخدام المتزامن لـ /tmp/snap.rootfs_XXXXXX وإعادة تسمية /tmp/snap.$SNAP_NAME، تم تشغيل حالتين من snap-confine. بمجرد إنشاء الحالة الأولى لـ /tmp/snap.rootfs_XXXXXX، تم حظر العملية وتشغيل الحالة الثانية باسم الحزمة rootfs_XXXXXX، مما أدى إلى تحول الدليل المؤقت /tmp/snap.$SNAP_NAME للحالة الثانية إلى الدليل الجذر /tmp/snap.rootfs_XXXXXX للحالة الأولى. بعد إعادة التسمية مباشرةً، تعطلت الحالة الثانية، واستُبدل /tmp/snap.rootfs_XXXXXX بتعديل لحالة السباق، كما حدث في استغلال ثغرة فبراير. بعد الاستبدال، تم إلغاء قفل التنفيذ من الحالة الأولى، وسيطر المهاجمون بشكل كامل على الدليل الجذر لـ snap.
كانت الخطوة الأخيرة إنشاء رابط رمزي /tmp/snap.rootfs_XXXXXX/tmp، والذي استخدمته دالة sc_bootstrap_mount_namespace() لربط مجلد /tmp الحقيقي القابل للكتابة بأي مجلد على نظام الملفات (FS)، لأن استدعاء دالة mount() يتبع الروابط الرمزية قبل التثبيت. يُحظر هذا التثبيت بقيود AppArmor، لكن الثغرة الأمنية استخدمت ثغرتين إضافيتين في multipathd لتجاوز هذا الحظر.
المصدر: opennet.ru
