CVE-2026-51992

ClickHouse के भीतर एक ऐसी सुविधा मौजूद है जो सही अनुमतियों वाले उपयोगकर्ता को विभिन्न डेटाबेस के साथ इंटरैक्ट करने और उन पर विशिष्ट क्वेरी चलाने के लिए डिक्शनरी बनाने की अनुमति देती है। 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 इंजनों के दस्तावेज़ में निम्नलिखित उल्लेख किया गया है:

PostgreSQL पक्ष पर SELECT क्वेरी प्रत्येक SELECT क्वेरी के बाद कमिट के साथ read-only PostgreSQL ट्रांज़ैक्शन के अंदर COPY (SELECT ...) TO STDOUT के रूप में चलती हैं।

चूंकि Postgres इंस्टेंस पर भेजे जाने से पहले डिक्शनरी में परिभाषित क्वेरी पर कोई अतिरिक्त सत्यापन नहीं होता है, इसलिए क्वेरी को ")" से शुरू करके "COPY(...) TO STDOUT" से बाहर निकला जा सकता है, जिससे एक ऐसा ट्रांज़ैक्शन बनता है जो read-only नहीं है। उदाहरण के रूप में, 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 एक त्रुटि लौटाएगा, जो दर्शाता है कि ClickHouse द्वारा अपेक्षित COPY फ़ंक्शन विफल हो गया है। हालाँकि, बाकी क्वेरी अभी भी बैकएंड PostgreSQL डेटाबेस पर निष्पादित होगी। PostgreSQL की PROGRAM सुविधा का दुरुपयोग करके, मनमाने कमांड चलाए जा सकते हैं।

संदर्भ

जबकि मूल परीक्षण संस्करण 25.8.10.7 पर किया गया था, जब रिपोर्ट 30 जनवरी, 2025 को प्रस्तुत की गई थी, उस समय नवीनतम संस्करण 26.3.9.8 था और यह भेद्यता अभी भी मौजूद थी। समीक्षा के बाद, मुद्दे को 10 अप्रैल, 2026 को "लागू नहीं" (not applicable) के रूप में चिह्नित किया गया, जिसमें निम्नलिखित कथन दिया गया:

नहीं - यह सुरक्षा कारणों से नहीं है बल्कि मुख्यतः दक्षता के लिए है। postgres क्रेडेंशियल + remote table function वाला उपयोगकर्ता पहले से ही बहुत कुछ कर सकता है या सीधे postgresql डेटाबेस से कनेक्ट होकर इन क्वेरी को निष्पादित कर सकता है।

इस प्रकार यह एक जोखिम नहीं है, यहाँ हमलावर को postgresql डेटाबेस के लिए वैध क्रेडेंशियल और CLickHouse पर एक वैध उपयोगकर्ता + postgresql table function का उपयोग करने की अनुमति की आवश्यकता होती है।

Postgresql डेटाबेस की सुरक्षा के लिए, उपयोगकर्ताओं को CLickHouse उपयोगकर्ता द्वारा उपयोग किए जाने वाले किसी भी postgresql क्रेडेंशियल के लिए उचित अनुमतियों का उपयोग करना चाहिए - और इसका मतलब है सीमित अनुमति, सीमित दायरा और सीधे डिफ़ॉल्ट "postgres" क्रेडेंशियल का उपयोग न करना।

इस प्रकार, यह इस लेखन के समय ClickHouse के नवीनतम संस्करणों पर भी लागू है:

ऐसा प्रतीत नहीं होता कि कोई फिक्स जारी किया जाएगा, जिसका अर्थ है कि ClickHouse के सभी वर्तमान और संभवतः भविष्य के संस्करण प्रभावित होंगे।