في نهاية مارس 2019 ، نشرت شركة Trustwave الأمريكية ، التي تعمل في مجال الأمن السيبراني وخدمات الحماية من التهديدات ، رسالة عن مشكلة عدم حصانة في PostgreSQL DBMS ، وهي موجودة في جميع الإصدارات بدءًا من PostgreSQL 9.3 إلى الإصدار 11.2. تم تسجيل مشكلة عدم الحصانة هذه في قاعدة بيانات ثغرة أمان المعلومات CVE (الثغرات المشتركة والتعرضات) تحت رقم CVE-2019-9193 . تسببت هذه الرسالة في ضجة كبيرة ، لأنه وفقًا لنظام تصنيف الثغرة CVSS (نظام تسجيل الثغرات العامة) ، تم تصنيف هذه الثغرة 9.0 على مقياس من 10 نقاط.
تم تعيين الثغرات والخصائص التالية:
- السرية الأثر (التأثير على السرية) - الكشف الكامل عن المعلومات ، يؤدي إلى الكشف عن جميع ملفات النظام.
- Integrity Impact (التأثير على النزاهة) - الفقدان الكامل لحماية النظام ، ونتيجة لذلك ، يصبح النظام بأكمله عرضة للخطر.
- تأثير التوفر - توافر المورد غير متاح تمامًا.
- وصول التعقيد منخفض. استخدام يتطلب القليل جدا من المعرفة أو المهارات.
- المصادقة - تتطلب من المهاجم تسجيل الدخول إلى النظام ، على سبيل المثال ، من خلال سطر الأوامر أو من خلال جلسة سطح المكتب أو واجهة الويب.
- حصل الوصول - لا.
- نوع (أنواع) الثغرة الأمنية (نوع الثغرة الأمنية) - تنفيذ التعليمات البرمجية.
الآن دعونا نتعرف على حقيقة ما يحدث.
في عام 2013 ، تمت إضافة التزام مرة أخرى في PostgreSQL 9.3 ، والذي ، على غرار الأمر \ copy meta في psql ، يسمح لك بنقل البيانات بين جداول PostgreSQL والملفات العادية في نظام الملفات. ينسخ COPY TO محتويات الجدول إلى الملف ، و COPY FROM - من الملف إلى الجدول (يضيف البيانات إلى تلك الموجودة بالفعل في الجدول). بخلاف الأمر \ copy meta-command ، الذي يتم تطبيقه على العميل ، يتم تطبيق الأمر COPY..TO / FROM على جانب الخادم. يحتوي أمر COPY على معلمة PROGRAM اختياري 'command' ، والتي تتيح للخادم تنفيذ 'command' وتمرير الإخراج القياسي إلى خادم PostgreSQL أو العكس. هذه المعلمة هي التي تسببت في حالة من الذعر والرسالة حول مشكلة عدم الحصانة ، حيث أنه وفقًا لـ Trustwave ، يسمح لك هذا الأمر بتنفيذ تعليمات برمجية عشوائية في سياق مستخدم نظام التشغيل. ومع ذلك ، هذا هو بالضبط ما قصد المطورين! في هذه المناسبة ، كان هناك منشور رسمي لمجموعة PostgreSQL Global Development Group (PGDG) ، بالإضافة إلى مراسلات في قائمة البريد الإلكتروني pgsql-general (CVE-2019-9193 حول COPY FROM / TO PROGRAM ) وتعليقات كبار المطورين ، على سبيل المثال Magnus Hagander ، على مدونته .
ولكن لفهم الجوهر ، التفاصيل مهمة. إليك ما كتب في الوثائق حول هذا: " لاحظ أن الأمر يتم تشغيله من خلال shell command ، لذلك إذا كنت تريد تمرير أي وسيطات إلى هذا الأمر من مصدر غير موثوق به ، فيجب عليك التخلص بعناية من جميع الأحرف الخاصة التي لها معنى خاص في shell ، أو لفحصها. لأسباب أمنية ، من الأفضل قصر نفسك على سطر أوامر ثابت أو على الأقل عدم السماح للمستخدمين بإدخال محتوى تعسفي فيه ".
بالإضافة إلى ذلك ، تشير الوثائق إلى أنه لا يُسمح سوى لمستعملي قاعدة البيانات بتنفيذ أمر COPY بملف أو أمر خارجي ، أو (في الإصدار 11 ظهر) أعضاء الأدوار المدمجة pg_read_server_files أو pg_write_server_files أو pg_execute_server_program ، حيث يتيح لك ذلك قراءة / كتابة أي ملفات وتشغيل أي ملفات البرامج التي يستطيع الخادم الوصول إليها. يمكن تقييد تنفيذ أمر في PROGRAM من خلال آليات التحكم في الوصول الأخرى التي تعمل في نظام التشغيل ، على سبيل المثال SELinux.
من الناحية الهيكلية ، لا يوجد حد أمان بين مستخدم قاعدة البيانات الفائق ومستخدم نظام التشغيل الذي تعمل عملية الخادم الخاصة به نيابةً عنه. وظائف COPY ... لم يغير PROGRAM 9.3 في PostgreSQL 9.3 أيًا مما ذكر أعلاه ، لكنه أضاف أمرًا جديدًا ضمن حدود الأمان نفسها الموجودة بالفعل. لذلك ، لا يمكن تشغيل خادم PostgreSQL باعتباره المستخدم الخارق لنظام التشغيل (على سبيل المثال ، الجذر).
توفر وظيفة COPY..TO / FROM ... PROGRAM نفسها إمكانيات غير محدودة لمعالجة البيانات ومعالجة ما بعد البيانات وضغط البيانات أثناء التنقل وما إلى ذلك. وحظر استخدام هذه الأدوات المفيدة سيكون خطأ. يتم تقديم أمثلة على COPY..TO / FROM ... إنشاء البرنامج على مدونة Michael Paquier.
الاستنتاج المهم الذي يلي من هذه القصة هو أنه عند تصميم وإنشاء قواعد البيانات ، من الضروري ألا نتذكر فقط الخصائص الوظيفية ، ولكن أيضًا أمن المعلومات واتباع القواعد التالية:
وبالتالي ، اكتشفنا أن CVE-2019-9193 ليست نقطة ضعف. لكن لا يجب عليك الاسترخاء. لا تفوت معلومات حول التحديثات والإصدارات الثانوية الجديدة التي تصحح نقاط الضعف المحددة ، والتي بدونها لا يستطيع أي مشروع كبير القيام بها.