
مقالة قصيرة مع أمثلة لفهم CVE-2023-43115
شرح موجز مع أمثلة للمساعدة في فهم CVE-2023-43115.
[!WARNING] كتبت هذا بشكل أساسي لنفسي لفهم المشكلة والتعرف على الأمن السيبراني. لذا قد توجد بعض الأخطاء.
لاستخدام جهاز IJS (الطباعة النافثة للحبر المحسّنة)، يجب على Ghostscript تشغيل خادم IJS. ويتم ذلك باستخدام المسار المحدد في معامل IjsServer. يمكن ضبط معامل IjsServer للإشارة إلى أي ملف مرغوب داخل نظام الملفات، ثم ينفّذ Ghostscript هذا الملف المحدد. ومن السهل هنا ملاحظة كيف يمكن إساءة استخدام هذا الأمر؛ على سبيل المثال، يمكنك تشغيل أمر ghostscript التالي لطباعة Hello World.
❯ gs -sDEVICE=ijs -sIjsServer="bash -c 'echo Hello World>&2'"
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Hello World
في حد ذاته، ليس هذا الأمر مشكلة كبيرة لأن هذا المعامل يجب أن يوفره المستخدم. ومع ذلك، من الممكن أيضًا تعيين هذا الجهاز ومعامل IJsServer داخل سكربت PostScript. انظر على سبيل المثال attack_example_*.ps (نفّذه باستخدام gs FILENAME). وهذا بدوره قد يسمح للمهاجم بتنفيذ تعليمات برمجية على الجهاز الذي يشغّل هذا السكربت. لكن هذه المشكلة معروفة وموثّقة رسميًا ويمكن منعها عن طريق تعيين LockSafetyParams إلى true.
لاستغلال هذا CVE بينما LockSafetyParams مفعّل، سيحتاج المهاجم إلى استغلال ناجح لتغيير LockSafetyParams. غير أنه إذا توفّر مثل هذا الاستغلال، فقد يكون هناك عدد من نواقل الهجوم الأخرى الممكنة اعتمادًا على الإصدار المستخدم.
وصف مؤلف الإصلاح كين شارب الحل الأمني LockSafetyParams المذكور بأنه حلٌّ ترقيعي لأنه مطبَّق في PostScript، وبالتالي يمكن أن يتأثر بتعليمات PostScript البرمجية. أدى هذا إلى عدة مشكلات أمنية في الماضي حيث كان من الممكن الكتابة فوق هذا المعامل (على سبيل المثال، انظر شرح CVE-2018-19475 ). يغيّر الإصلاح آلية الحماية التي تمنع تعيين مسار IjsServer من LockSaftyParams إلى المعامل الجديد -dSAFER، والذي لا يمكن أن يتأثر بتعليمات PostScript البرمجية.
[!NOTE] تنص التوثيق الخاصة بالنسخة الضعيفة 9.55.0 بالفعل على استخدام معامل -dSAFER، وهو ما يبدو أنه خطأ في التوثيق.