CVE-2026-51992

داخل ClickHouse، توجد ميزة تسمح للمستخدم الذي يمتلك الصلاحيات الصحيحة بإنشاء قواميس (dictionaries) للتفاعل مع قواعد بيانات مختلفة وتنفيذ استعلامات محددة عليها. بالنسبة إلى PostgreSQL، يتم تغليف استعلامات SELECT في عبارة COPY( {QUERY} ) TO STDOUT قبل تنفيذها على قاعدة البيانات. بإضافة قوس إلى قاموس تم إنشاؤه، يمكن الإفلات من عبارة COPY( {QUERY} ) TO STDOUT وتنفيذ عبارات SQL عشوائية، مما قد يؤدي بدوره إلى تشغيل أوامر عشوائية على خادم قاعدة البيانات.

التفاصيل

يتم إنشاء قواميس PostgreSQL بالبنية التالية:

SOURCE(POSTGRESQL(
    port 5432
    host 'postgresql-hostname'
    user 'postgres_user'
    password 'postgres_password'
    db 'db_name'
    table 'table_name'
    replica(host 'example01-1' port 5432 priority 1)
    replica(host 'example01-2' port 5432 priority 2)
    where 'id=10'
    invalidate_query 'SQL_QUERY'
    query 'SELECT id, value_1, value_2 FROM db_name.table_name'
))

تذكر الوثائق الخاصة بمحركات PostgreSQL المستخدمة في القواميس ما يلي:

تعمل استعلامات SELECT على جانب PostgreSQL كـ COPY (SELECT ...) TO STDOUT داخل معاملة PostgreSQL للقراءة فقط مع الالتزام بعد كل استعلام SELECT.

نظرًا لعدم وجود تحقق إضافي من الاستعلامات المعرّفة في القاموس قبل إرسالها إلى مثيل Postgres، يمكن الإفلات من "COPY(...) TO STDOUT" ببدء الاستعلام بـ ")"، مما ينشئ معاملة ليست للقراءة فقط. على سبيل المثال، يمكن استخدام الاستعلام التالي في ClickHouse لإنشاء قاموس Postgres "سيء":

CREATE DICTIONARY exec_dict(id UInt64, value UInt64 DEFAULT 0) PRIMARY KEY id SOURCE(POSTGRESQL(port 5432 host '172.17.0.3' user 'postgres' password 'password' db 'postgres' query 'SELECT 1) TO PROGRAM \'id>/tmp/test\';-- ')) LAYOUT(DIRECT())

بمجرد إنشاء القاموس، يمكن تحميله داخل ClickHouse بالإشارة إليه. سيعيد ClickHouse خطأً يُشير إلى فشل دالة COPY المتوقعة من ClickHouse. ومع ذلك، سيستمر تنفيذ بقية الاستعلام على قاعدة بيانات PostgreSQL الخلفية. من خلال إساءة استخدام ميزة PROGRAM في PostgreSQL، يمكن تشغيل أوامر عشوائية.

السياق

بينما كان الاختبار الأصلي على الإصدار 25.8.10.7، عندما تم تقديم التقرير في 30 يناير 2025، كان أحدث إصدار في ذلك الوقت هو 26.3.9.8 وكانت الثغرة لا تزال موجودة. بعد المراجعة، وُسمت المشكلة بأنها "غير قابلة للتطبيق" في 10 أبريل 2026، مع البيان التالي:

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

على هذا النحو، لا تمثل هذه مخاطرة؛ فالمهاجم هنا يحتاج إلى بيانات اعتماد صالحة لقاعدة بيانات PostgreSQL ومستخدم صالح على ClickHouse بالإضافة إلى إذن لاستخدام دالة جدول PostgreSQL.

أما بالنسبة لحماية قاعدة بيانات PostgreSQL، فيجب على المستخدمين استخدام صلاحيات منطقية لأي بيانات اعتماد PostgreSQL يستخدمها مستخدم ClickHouse - وهذا يعني صلاحيات محدودة ونطاقًا محدودًا، وليس استخدام بيانات اعتماد "postgres" الافتراضية مباشرة.

وبالتالي، فإن هذا لا يزال قابلاً للتطبيق على أحدث إصدارات ClickHouse في وقت كتابة هذا التقرير:

من غير المرجح أن يتم إصدار إصلاح، مما يعني أن جميع الإصدارات الحالية وربما المستقبلية من ClickHouse ستتأثر.