فك ترميز JPEG XL تلقائيًا في مسار معاينة رسائل iOS

نتيجة لسطح تسليم لـ CVE-2026-28956 (AppleJPEGXL)، بالإضافة إلى نسبة التصحيح عبر مقارنة التصحيحات وفحص واقعي لموثوقية الـ PoC العام.

الخلاصة — الحكمة التقليدية (وقياسنا السابق مع EXR) تقول إن رسائل iOS تعرض المرفقات غير JPEG/PNG/HEIC كملفات عامة دون فك ترميزها. JPEG XL يكسر هذا الافتراض: مرفق .jxl يُمرَّر إلى وحدة فك الترميز في مسار معاينة الرسائل. لاحظنا أن ImageIO داخل MobileSMS يحاول فك ترميز محتوى JXL عند الاستلام، دون أي تفاعل من المستخدم. وهذا يجعل AppleJPEGXL سطح هجوم حيًا بصفر نقرات بطريقة لا تنطبق على صيغ فئة EXR.

المحتويات

الملف	الوصف
`PROBE_RESULT.md`	فحص سطح التسليم: الإعداد، أدلة المرسل، سجل النظام للجهاز الذي يعرض محاولات فك الترميز، مستويات الحكم
`DIFF.md`	مقارنة التصحيحات iOS 26.4.2 مقابل 26.5: CVE-2026-28956 يُنسب إلى AppleJPEGXL (libjxl 0.10.4 ← 0.10.5)؛ مرشحو CVE-2026-43661 في ImageIO
`pocs/poc.jxl`	المشغّل العام بحجم 149 بايت (من مقال المؤلف)، المستخدم كحمولة الفحص
`pocs/poc_brand.heic`, `pocs/poc_mif1.heic`	نفس البايتات مع تغيير علامة ftyp إلى `heic` / `mif1` — تُستخدم لاختبار فحص المحتوى مقابل UTI المُعلَن
`pocs/jxldec.m`	أداة فك ترميز CGImageSource مصغّرة (تُترجم عبر التجميع لنظام iOS)، تُستخدم لاختبارات فك الترميز على الجهاز

النتيجة

أُرسلت ثلاثة مرفقات عبر iMessage (نقل أزرق، بايتات سليمة وفق chat.db للمرسل) إلى iPhone فعلي يعمل بنظام iOS 18.6.2، مع تشغيل idevicesyslog لمراقبة أسطح فك الترميز:

poc.jxl (UTI public.jpeg-xl)
poc_brand.heic (نفس البايتات، علامة heic)
poc_mif1.heic (علامة mif1)

سجل الجهاز (MobileSMS):

MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]

أمران بارزان:

وحدة فك الترميز عملت أصلًا. للمقارنة، مرفق EXR في نفس الإعداد لا يُنتج أي نشاط فك ترميز — تعرض الرسائل أيقونة ملف ولا تستدعي وحدة فك الترميز أبدًا. JXL يُعامَل كصورة تستحق فك الترميز في المعاينة.
فحص المحتوى يتغلب على العلامة المُعلَنة. المتغيرات ذات علامة .heic تم فحصها أيضًا كـ 'JXL ' عبر بايتات التوقيع وتوجيهها إلى وحدة فك ترميز JXL، لذا اسم ملف .heic لا يوجّه التحليل إلى قارئ HEIF — وبالمقابل مرفق .jxl عادي يصل بالفعل إلى AppleJPEGXL. لا حاجة لأي حيل حاويات للتسليم.

أخطاء -58 هي من وحدة فك الترميز الأقدم (iOS 18.6.2) التي ترفض بنية jxlc المكررة التالفة؛ النقطة هي أن التحليل حدث.

الفحص الواقعي (بصراحة)

كون السطح مفتوحًا لا يجعل الـ PoC العام هجومًا عمليًا بصفر نقرات:

المشغّل العام بحجم 149 بايت لا يتسبب في انهيار على iOS 26.4.2 أو iOS 18.6.2 أو macOS 26.3.1 عبر فك ترميز CGImageSource بسيط (10/10 عمليات تشغيل تحت MallocScribble، بالإضافة إلى متغير بمشغّل مكرر 8 مرات).
مجموعة من ملفات الإطارات العدائية المصممة خصيصًا (إزاحات frame_origin مصنوعة، تستهدف مسار خط أنابيب العرض منخفض الذاكرة الذي يصلّبه الإصلاح العلوي الفعلي — libjxl PR #4495) تُفك ترميزها بنجاح أيضًا على iOS 26.4.2.
مقال المؤلف نفسه يلاحظ أن تحليل السبب الجذري قد يكون غير مكتمل وأن دليل الانهيار لديه أُنتج في Safari على macOS مع مكتبة اعتراض.

إذًا: التسليم بصفر نقرات مُثبت؛ التشغيل الموثوق غير مُثبت. الخطأ الذي أصلحته Apple حقيقي (انظر DIFF.md — مسار Plane/float منخفض الذاكرة أُعيدت كتابته وتقويته)، لكن تحويله إلى تلف ذاكرة حتمي على iOS هو مشكلة تسليح لا يحلها الأثر العام.

لماذا النشر على أي حال

كل من سألناه (وتجربتنا مع EXR) افترض أن مرفقات غير JPEG/PNG/HEIC لا تُفك ترميزها في معاينة الرسائل. JXL يُفك ترميزها. هذا توسيع ملموس وقابل للاختبار لسطح هجوم صفر النقرات، ويعني أن أخطاء AppleJPEGXL تستحق البحث مع وضع تسليم iMessage في الاعتبار، وليس فقط WebContent.

لأغراض البحث التعليمي والدفاعي. اختبر فقط على أجهزة تملكها.

CVE-2026-28956-jxl-messages-surface

الأكثر شعبية