ITScape: الهروب من الضيف إلى المضيف في KVM/arm64

الملخص

يصف هذا المستند الثغرة الأمنية ITScape (CVE-2026-46316) التي أبلغ عنها وعالجها Hyunwoo Kim (@v4bel). وهي ثغرة هروب من KVM تتيح للضيف الهروب إلى المضيف في بيئة KVM/arm64 وتنفيذ أوامر على المضيف بامتياز النواة (الجذر). وفقًا لأفضل ما هو معروف علنًا، يعد هذا أول بحث استغلالي للهروب من الضيف إلى المضيف يستهدف KVM/arm64.

يستغل ITScape حالة سباق (race condition) في محاكاة vGIC-ITS (خدمة ترجمة المقاطعات) الخاصة بـ KVM/arm64. فهو يُطلق الثغرة بإجراءات من جانب الضيف فقط للهروب إلى المضيف، ويمكنه تهديد العزل بين الضيف والمضيف في مضيفات KVM/arm64 التي تقبل ضيوفًا غير موثوقين، ولا سيما السحابات العامة arm64 متعددة المستأجرين.

خلافًا لعمليات الهروب من QEMU المنشورة بشكل شائع، فإن الثغرة تكمن في KVM داخل النواة وليس في مساحة مستخدم QEMU، لذا فهي تعمل بشكل مستقل عن محاكاة QEMU، ويمكنها تنفيذ أوامر على المضيف بامتياز نواة المضيف بدلًا من امتياز عملية مستخدم (مثل QEMU).

للحصول على المعلومات التقنية التفصيلية، انظر هنا.

[!NOTE] بعد الإبلاغ عن هذه الثغرة إلى [email protected]، انتهى الحظر المتفق عليه، لذلك نُشرت وثيقة ITScape هذه الآن. للاطلاع على الجدول الزمني للإفصاح، راجع وثيقة التفاصيل التقنية.

هيكل PoC

للاختبار الآمن، يُنصح بتشغيل PoC تحت QEMU TCG. (لا علاقة لإطلاق الثغرة بـ QEMU.) عند تشغيله تحت QEMU TCG، يكون له الهيكل التالي.

QEMU TCG: emulates an arm64 CPU (including EL2) so an arm64 kernel runs as the KVM host
   └─ arm64 Host Kernel: the KVM host and the escape target
        └─ poc: opens the HOST's /dev/kvm and creates one guest VM "G" (uid=1000)
             └─ 1. G's guest code (run by poc via KVM_RUN) performs GIC/ITS MMIO
                2. traps into the HOST's in-kernel KVM -> double-put -> HOST kernel code-exec

هذا PoC ليس استغلالًا كامل التسلح يعمل فورًا في بيئة سحابية arm64، بل هو كود توضيحي يعيد إنتاج الثغرة وسلسلة الاستغلال الكاملة فوق اختبار kvm selftest. من المتوقع أن المهاجم الذي يعرف تنفيذ حزمة المحاكاة الافتراضية للسحابة المستهدفة لن يجد الانتقال إلى التسلح الكامل صعبًا في حد ذاته، لكنه يستلزم نقل البناء المباشر من جانب المضيف في الاختبار إلى مسار حقيقي يقوده الضيف، وضبط العناوين والأداة (gadget) والإزاحات وتوقيت السباق وما إلى ذلك بما يتوافق مع إصدار النواة وإعداداتها المستهدفة. يوجد استغلال حقيقي كامل التسلح لكنه لن يُنشر.

استخدام PoC

1. يُبنى PoC فوق اختبار kvm selftest في شيفرة مصدر نواة لينكس. نزّل شيفرة نواة v7.1-rc6، وهي الإصدار الذي يسبق معالجة الثغرة مباشرة، ثم ابنِ PoC باستخدام سكربت البناء. بعد ذلك ابنِ صورة النواة باستخدام إعداد kconfig المرفق.

# ./build.sh <linux>/tools/testing/selftests/kvm

2. ضع PoC المبني في initramfs مناسب، ثم شغّل qemu استنادًا إلى سكربت QEMU المرفق.

# ./qemu.sh <kernel-image> <initramfs>

3. بعد إقلاع QEMU TCG، شغّل poc. عند نجاح الاستغلال، يهرب من الضيف وينشئ الملف /ITScape على المضيف.

# ./poc
...
[+] /ITScape created by the host kernel (owner uid=0). verify:  ls -la /ITScape
# ls -la /ITScape
-rw-r--r--    1 0        0                0 Jun  9 00:02 /ITScape

هذا PoC مُعد لتوفير معلومات دقيقة. لا تستخدمه على أنظمة غير مصرح لك باختبارها.

الإصدارات المتأثرة

يغطي ITScape (CVE-2026-46316) النطاق الممتد من 8201d1028caa (2024-04-25) إلى 13031fb6b835 (2026-06-05).

الأسئلة الشائعة

هل ينبغي أن أقلق؟

إذا كنت تشغّل مضيف KVM من نوع arm64 يقبل ضيوفًا متعددي المستأجرين، أو تستخدم مثيلًا (instance) فوقه، فتأكد من تطبيق تصحيح 13031fb6b835 على نواة المضيف (المشغلون مباشرةً، والمستأجرون عبر مزودهم). كذلك، نظرًا لأن هذه فئة ثغرات جديدة، فمن المتوقع ظهور مزيد من الاختلافات والثغرات اللاحقة، لذا ترقّب. ومع ذلك، ستحتاج إلى التمييز بين ما إذا كانت الثغرة اللاحقة قابلة للإطلاق فعلًا بإجراءات من جانب الضيف فقط دون أي إجراء من جانب المضيف، وما إذا كانت قابلة للاستغلال فعلًا.

هل تؤثر هذه الثغرة على x86 أو بنى معمارية أخرى؟

لا. الثغرة تقع في arch/arm64/kvm/vgic/. إذا لم تكن على مضيف KVM من نوع arm64، فلست بحاجة إلى القلق بشأن هذه الثغرة.

هل أحتاج إلى صلاحيات الجذر داخل ضيف VM؟

نعم. تشغيل GIC/ITS MMIO يتطلب امتياز نواة الضيف (EL1). عندما يُخصص لك مثيل على سحابة عامة، يكون لديك عادةً صلاحيات الجذر على VM الخاص بك، لذا يتحقق هذا الشرط. في سيناريو دون صلاحيات جذر للضيف، يجب ربطها بثغرة تصعيد صلاحيات محلية (LPE) مثل Dirty Frag.