إصدار ووردبريس ٧.٠.٤ أغلق ثغرة تنفيذ تعليمات برمجية: من كان في خطر فعلاً

ماذا عالج هذا الإصدار

أدرج فريق الأمن بنداً واحداً: تنفيذ تعليمات برمجية عن بعد من مستخدم موثق بصلاحية كاتب أو أعلى، عبر رفع ملف خبيث، على المواقع التي تستعمل Imagick وGhostscript. الإبلاغ جاء من فريق pwn.ai.

قائمة الملفات المعدلة في صفحة الإصدار سطر واحد لا غير:

/wp-includes/class-wp-image-editor-imagick.php

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

لماذا رجع الإصلاح حتى الإصدار ٤.٧

نشر ووردبريس الإصلاح على ثلاثة وعشرين فرعاً قديماً، نزولاً إلى ٤.٧.٣٥. يعني أن موقعاً ما زال على ٥.٢ يجد نسخة مصححة بانتظاره. أما ٤.٦ وما قبله فلم يعد يتلقى تحديثات أمنية أصلاً.

هذا القرار وحده يقول شيئاً عن حجم المسألة، فووردبريس لا يعيد إصلاح خلل عادي ثماني سنوات إلى الوراء.

ثلاثة أوامر تحسم موقعك

الترتيب مهم: الإصدار أولاً، ثم Imagick، ثم Ghostscript. وإذا غاب أحد الأخيرين فأنت خارج نطاق الثغرة من الأساس.

wp core version
php -r 'echo extension_loaded("imagick") ? Imagick::getVersion()["versionString"] : "no imagick";'
gs --version

هذا ما أجاب به خادمنا في ١٥ أغسطس ٢٠٢٦:

7.0.4
ImageMagick 6.9.12-98 Q16 x86_64 18038
10.02.1

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

الفخ الذي أضاع علينا الوقت: ملف policy.xml

كل دليل لتقوية ImageMagick ينصحك بإغلاق ملف policy.xml حتى تتعطل مفسرات PostScript وPDF. النصيحة سليمة، والمشكلة في مكان آخر.

في التثبيت القياسي لـ ImageMagick 6 على دبيان وأوبونتو، تقع تلك الأسطر داخل كتلة التعليقات التوضيحية في الملف، لا داخل الإعدادات الفعالة. بحثنا عن السطر فوجدناه واطمأننا لحظة، ثم اختبرنا أثره فتبين أنه معطل.

أمران يفصلان الظن عن اليقين. الأول يعرض السياسات النافذة فعلاً، والثاني يثبت أن Ghostscript ما زال يستدعى:

identify -list policy
convert sample.pdf out.png

إن خلت نتيجة الأمر الأول من أي صف بعنوان Coder فلا قيد لديك على المفسرات، مهما بدا مكتوباً في الملف. وإن أعاد الأمر الثاني خطأ من Ghostscript لا خطأ صلاحيات، فالطريق مفتوح. وهذا ما حدث عندنا.

احسب إذن كم شخصاً يملك صلاحية كاتب في لوحتك. ووردبريس يسمح للكاتب افتراضياً برفع صيغ pdf وpsd وxps وoxps، وهي الصيغ نفسها التي تنتهي عند Ghostscript.

إضافة الحماية ما كانت لتوقف هذا

جملة مكلفة على من يبيع إضافات حماية، لكنها صحيحة.

تعمل Wordfence وأمثالها على طبقة الطلب: حمولة مشبوهة، عنوان سيئ، محاولة دخول فاشلة. أما هنا فالرفع مشروع تماماً، ومن مستخدم يملك حق الرفع فعلاً، والمعالجة تجري داخل ملف من ملفات النواة. لا قاعدة في جدار حماية التطبيقات ترى في ذلك شذوذاً.

ثلاثة أشياء هي التي أفادت، وكلها مجانية: تحديث تلقائي للنواة يبقى مفعلاً، وأقل عدد ممكن من حسابات الكتاب، وتثبيت ImageMagick مقيد حقاً لا ظاهرياً.

وحجم الخطر الحقيقي

إن كنت المستخدم الوحيد لموقعك فتعرضك العملي هنا قارب الصفر، لأن ثغرة تتطلب توثيقاً بصلاحية كاتب تعني أن المهاجم يحتاج حساباً أولاً.

الخطر الفعلي في مكان آخر.

مواقع بتسجيل مفتوح. منصات متعددة الكتاب. مدونات شركات يملك فيها عشرة أشخاص حق النشر ولم يراجع أحد قائمة المستخدمين منذ سنتين.

إن كان هذا وصفك، فالترقيع نصف العمل، والنصف الثاني مراجعة تلك القائمة.

ماذا تفعل الآن

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

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

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

المصادر

• إعلان إصدار ووردبريس ٧.٠.٤ للتاريخ ووصف الثغرة والجهة المبلغة
• صفحة الإصدار ٧.٠.٤ لقائمة الملف المعدل والفروع التي رجع إليها الإصلاح

روجع المصدران ونفذت جميع الأوامر أعلاه على خادمنا في ١٥ أغسطس ٢٠٢٦.