CVE-2026-31431 (Copy Fail) - كيف خفّفنا أثره

كُشف الأسبوع الماضي عن ثغرة خطيرة لتصعيد الصلاحيات محلياً في Linux kernel: CVE-2026-31431، الملقبة باسم "Copy Fail". تؤثر الثغرة في نطاق واسع من إصدارات kernel عبر توزيعات Linux الحديثة، وظهر استغلال علني لها بسرعة بعد الإفصاح.

أريد أن أكون واضحاً بشأن ما حدث، وما يعنيه ذلك لـ Appbox، وما فعلناه حياله. الخلاصة: بفضل الطريقة التي بُنيت بها حاوياتنا، كانت التطبيقات التي تعمل مع user namespace remapping محمية بالفعل من تحوّل ذلك إلى host root حتى قبل طرح نُوى kernel المصححة. بالأمس (4 مايو 2026)، أجرينا أيضاً صيانة طارئة لترقية كل خادم إلى kernel مصحح، لذلك اختفت الثغرة الآن بالكامل من أسطولنا.

ما هي "Copy Fail"؟

CVE-2026-31431 هي ثغرة في واجهة AF_ALG التشفيرية داخل kernel. عبر الارتباط بتشفير محدد (authencesn(hmac(sha256),cbc(aes))) وإساءة استخدام طريقة إدراج kernel للصفحات داخل مخزن مؤقت مؤقت، يستطيع مستخدم محلي غير مميز كتابة أجزاء عشوائية بحجم 4 بايت مباشرة داخل page cache لملفات لا يفترض أن يملك صلاحية تعديلها، بما في ذلك ملفات SUID الثنائية مثل /usr/bin/su.

بعد الكتابة فوق نسخة page cache من su بملف ELF خبيث صغير، يشغّل الاستدعاء التالي كود المهاجم بصفة UID 0. عندها تنتهي اللعبة بالنسبة إلى المضيف.

للتفاصيل التقنية العميقة (تفكيك shellcode، تتبعات syscall، وكل التفاصيل)، تُعد كتابة Andrea Veri ممتازة: CVE-2026-31431: Copy Fail vs. rootless containers. كما قام بعمل إثبات، باستخدام eBPF وuid_map، لما سنتحدث عنه تالياً: أن user namespaces تُبطل فعالية هذا الاستغلال.

لماذا كانت تطبيقات Appbox مخففة بالفعل

يعتمد الاستغلال على أن setuid(0) يمنح فعلياً صلاحية host root. في حاوية تعمل مع user namespaces مفعّلة، ليس هذا ما يحدث.

تربط user namespaces مساحة UID داخل الحاوية بنطاق UID مختلف وغير مميز على المضيف. لذلك عندما ينجح الاستغلال داخل الحاوية وتُرجع setuid(0) نتيجة ناجحة، تكون shell الناتجة التي تبدو "root" مرتبطة بـ مستخدم مضيف عادي غير مميز، لا بـ root الحقيقي. يعمل shellcode ويتغير الموجه إلى #، لكن على المضيف:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

هذا كل شيء. لا وصول إلى ملفات المضيف، ولا /etc/shadow، ولا host root. حدود namespace الخاصة بالحاوية تمنع هذا من التحول إلى هروب بصلاحية root على المضيف.

على مستوى المنصة، يحصل كل Appbox على Docker daemon خاص به يبدأ مع user namespace remapping مفعّل. في pseudocode، يبدو الأمر أقرب إلى هذا:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

ويستند ذلك الربط إلى نطاق UID/GID فرعي مخصص على المضيف:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

وفوق ذلك، لا تزال تعريفات التطبيقات قادرة على تجاوز UsernsMode صراحة عندما يحتاج تطبيق ما إلى معالجة خاصة:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

لذلك فالوصف الدقيق هو: user namespace remapping جزء من الإعداد الافتراضي للمنصة، والاستثناءات لكل تطبيق تكون صريحة. توجد مجموعة صغيرة من التطبيقات التي تحتاج إلى إعدادات مختلفة لأنها تعرض وظائف تتطلب قدرات إضافية، وتُعالج هذه الحالات بشكل منفصل.

بعبارة أخرى: بالنسبة إلى التطبيقات التي تعمل بالإعداد الطبيعي المعاد ربطه، لم يكن بإمكان Copy Fail تحويل اختراق حاوية إلى host root.

ما الذي أردنا إصلاحه رغم ذلك

تمنع user namespaces الهروب إلى المضيف، لكنها لا تجعل الثغرة تختفي داخل الحاوية. كان المهاجم سيظل قادراً على التصعيد إلى "container root" داخل حدود التطبيق، وهو أمر سيئ من ناحية النظافة الأمنية حتى لو كان محصوراً. كان kernel نفسه ضعيفاً، وأردنا إزالة ذلك.

بمجرد أن علمنا بالثغرة، بدأنا فوراً تقييم مدى تعرضنا لها. ومع أن user namespace remapping كان يمنع بالفعل جانب الهروب إلى المضيف في إعداد التطبيقات العادي لدينا، فقد أردنا إزالة ثغرة kernel الأساسية بأسرع ما يمكن.

ما فعلناه بالأمس

في ليلة الأحد جدْولنا صيانة طارئة ليوم الاثنين، 4 مايو 2026، وهي أقرب نافذة تمكنا فيها من طرح ترقية kernel على مستوى الأسطول.

خلال النافذة:

• رُقّي كل مضيف باستخدام حزم Debian kernel الرسمية التي تحتوي على إصلاح "Copy Fail".
• كان الهدف بسيطاً: إزالة مسار kernel الضعيف بالكامل، لا الاكتفاء بالاعتماد على عزل namespaces القائم لدينا.

اكتملت الصيانة. كل مضيفات Appbox تعمل الآن على kernel مصحح.

ماذا يعني ذلك لك

• لم تكن بحاجة إلى فعل أي شيء. استمرت تطبيقاتك في العمل، وكانت أي ومضات انقطاع قصيرة خلال نافذة الصيانة هي الأثر الوحيد المرئي للعملاء.
• حتى قبل تصحيح الأمس، كان user namespace remapping يعني أن هذه الثغرة لا تستطيع تحويل اختراق تطبيق عادي إلى host root. هذا بالضبط نوع السيناريو الذي صُمم نموذج العزل هذا من أجله.
• مستقبلاً، لن تتغير سياستنا: تبقى user namespaces مفعلة افتراضياً، وتمر الاستثناءات القليلة جداً بمراجعة أمنية إضافية.

الصورة الأكبر

هذه واحدة من تلك CVEs التي يبدو عنوانها ("تصعيد صلاحيات محلي، استغلال علني، كل kernel حديث متأثر") كارثياً، وبالنسبة إلى كثير من بيئات المستأجرين المتشاركين كان كذلك فعلاً. سبب أنه لم يكن كارثياً لنا هو السبب نفسه الذي جعلنا نتخذ قبل سنوات قرارات معمارية تكلفنا أحياناً قليلاً من التوافق: نحن نشغّل التطبيقات بمبدأ أقل الصلاحيات مدمجاً في طبقة الحاويات، لا ملصقاً بها لاحقاً.

الدفاع المتعدد الطبقات ينجح فعلاً. ثغرة في طبقة kernel؟ التقطتها طبقة namespace. ثغرة في طبقة namespace؟ تسقط capability drops وseccomp معظمها. لا ندّعي أن أي طبقة واحدة مثالية، بل نحرص فقط على وجود طبقة تالية دائماً.

إذا كانت لديك أي أسئلة حول هذا الأمر، أو حول كيفية إعداد تطبيقاتك المحددة، فتواصل معنا من فضلك.

هل لديك أسئلة؟ تواصل معنا على support@appbox.co أو افتح تذكرة عبر billing.appbox.co.