تمثل ثغرة Dirty Frag ثاني تهديد حاد لنظام Linux خلال أسبوعين، حيث تسمح للمستخدمين منخفضي الامتيازات والحاويات بالوصول إلى صلاحيات المسؤول على الأنظمة المتأثرة. تم تسريب كود الاستغلال عبر الإنترنت قبل ثلاثة أيام من 12 مايو 2026، وهو يعمل بشكل موثوق عبر جميع توزيعات Linux تقريباً دون التسبب في أعطال.
اكتشف الباحث Hyunwoo Kim الثغرة وأفصح عنها في أواخر الأسبوع الماضي. يجمع الاستغلال بين كود للثغرتين المرقومتين CVE-2026-43284 و CVE-2026-43500. بعد الإفصاح الأولي، قام شخص آخر بتسريب التفاصيل الرئيسية، مما حوّلها إلى تهديد من نوع zero-day فعلي. نشر Kim بعد ذلك الكود المصدري لاستغلال proof-of-concept الذي طوّره. على الرغم من أن كلا الثغرتين في kernel كانت لديهما تصحيحات متوفرة، إلا أن أياً من توزيعات Linux الرئيسية لم تكن قد دمجت الإصلاح في وقت الإفصاح.
قالت Microsoft إنها رصدت علامات تدل على أن المتسللين يجربون Dirty Frag في البيئة البرية. كود الاستغلال المسرب حتمي في الطبيعة، مما يعني أنه يعمل بنفس الطريقة في كل مرة عبر توزيعات Linux مختلفة. تجعل هذه القابلية للتنبؤ فعالة بشكل خاص في البيئات المشتركة حيث تستخدم عدة أطراف نفس الخادم.
كيف تستغل ثغرة Dirty Frag أخطاء kernel في Linux
تنبع كلا ثغرات تصعيد الامتيازات من أخطاء في طريقة معالجة kernel لـ page caches المخزنة في الذاكرة. تسمح للمستخدمين غير الموثوقين بتعديل الـ caches في مكونات معالجة الشبكة وشظايا الذاكرة. يستهدف CVE-2026-43284 عمليات esp4 و esp6 على مسار IPsec ESP receive. يستهدف CVE-2026-43500 نظام rxrpc، الذي يتعامل مع حمولات RxRPC باستخدام عمليات تشفيرية.
شرح الباحثون في Automox أن Dirty Frag تنتمي إلى نفس عائلة الأخطاء كما الثغرات السابقة Dirty Pipe و Copy Fail. يستخدم الاستغلال splice() لزراعة مرجع إلى صفحة page-cache للقراءة فقط، مثل /etc/passwd أو /usr/bin/su، في بنية kernel. يقوم كود kernel على جانب المستقبل بعد ذلك بإجراء عمليات تشفيرية على تلك الصفحة، مما يعدّل page cache في الذاكرة. كل قراءة لاحقة للملف ترى النسخة التالفة، حتى لو كان لدى المهاجم فقط حق الوصول للقراءة.
عند تسلسل الاستغلالتين معاً، يسمحان للمهاجمين بالوصول إلى صلاحيات المسؤول على كل توزيعة رئيسية تم اختبارها. لا أحد الاستغلالتين المستخدمة بشكل منفصل موثوق. تستخدم بعض إعدادات Ubuntu AppArmor لمنع المستخدمين غير الموثوقين من إنشاء محتويات namespace، مما يحيد تقنية ESP. لا تقوم معظم التوزيعات الأخرى بتشغيل rxrpc.ko بشكل افتراضي، مما يحيد ذراع RxRPC. ومع ذلك، فإن استخدام كلا الاستغلالين معاً يتجاوز هذه الحماية.
تهديد فوري لأنظمة Linux
صرّح باحثون أمن من Aviatrix أن الثغرة تمثل تهديداً فورياً وكبيراً للـ الأمن السيبراني عبر البنية التحتية لـ Linux. يجب على المؤسسات تطبيق التصحيحات وتنفيذ تدابير التخفيف لحماية الأنظمة من التسوية. لاحظ باحثون من Microsoft أن Dirty Frag تقدم مسارات هجوم kernel متعددة تتضمن مكونات شبكة rxrpc و esp/xfrm. يبدو أن الاستغلال مصمم لزيادة الاتساق عبر البيئات الضعيفة، بدلاً من الاعتماد على نوافذ توقيت ضيقة أو حالات فساد غير مستقرة شائعة في استغلالات تصعيد الامتيازات الأخرى على Linux.
بمجرد تنفيذ الاستغلالات بنجاح، يمكن للمهاجمين استخدام وصول SSH أو تنفيذ web-shell أو container escapes. يمكنهم أيضاً تسوية حسابات منخفضة الامتيازات لإنشاء persistent access. يخلق هذا مخاطر خاصة في بيئات الاستضافة المشتركة والنشر المعتمد على الحاويات.
حالة التصحيح والتوفر عبر التوزيعات
في وقت الإفصاح، كان عدة موزعي Linux قد أصدروا تصحيحات. كانت الموزعون المعروفون الذين لديهم تصحيحات متاحة يشملون Debian و AlmaLinux و Fedora. يجب على مستخدمي التوزيعات الأخرى التحقق مع مزودهم الرسمي لتوفر التصحيح. تستمر مجتمع الأمن السيبراني في تتبع طرح التصحيح عبر نظام Linux الأوسع.
تتبع كل من ثغرات kernel الأصلية والاستغلالات المشتقة نمطاً أسسته أخطاء page-cache السابقة. استهدفت ثغرة Dirty Pipe من عام 2022 أيضاً عيوب تسمح للمهاجمين بالكتابة فوق page caches. استهدفت ثغرة Copy Fail من الأسبوع الماضي caching خاطئ في عملية authencesn AEAD template المستخدمة لأرقام التسلسل الموسعة IPsec. تبرز هذه المشكلات المتكررة في kernel التحديات النظامية في إدارة الذاكرة والتعامل مع الـ cache.
توصيات مستخدمي Linux
أفضل استجابة لأي شخص يستخدم Linux هي تثبيت التصحيحات فوراً. بينما قد تتطلب الإصلاحات إعادة تشغيل، فإن الحماية من تهديد مهم مثل Dirty Frag تفوق تكلفة الاضطرابات التشغيلية. يجب على أي شخص غير قادر على تثبيت التصحيحات فوراً اتباع خطوات التخفيف المنشورة من قبل باحثي الأمن السيبراني.
لاحظ الباحثون في Wiz التابعة لـ Google أن الاستغلالات ستكون أقل احتمالاً للخروج من بيئات حاويات معزولة مثل Kubernetes عند وضع إعدادات الأمان الافتراضية موضع التنفيذ. ومع ذلك، يبقى الخطر كبيراً للأجهزة الافتراضية والبيئات الأقل تقييداً. يجب على المؤسسات أن تعطي الأولوية لترقيع الأنظمة في سيناريوهات الاستضافة المشتركة والنشر المعتمد على الحاويات وأي بيئة يتمتع فيها المستخدمون غير الموثوقون بإمكانية الوصول المحلي.
