CVE-2026-66907

सारांश

Apache Camel Google Storage घटक में सापेक्ष पथ ट्रैवर्सल भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 4.0.0 से 4.14.9 से पहले, 4.15.0 से 4.18.4 से पहले, 4.19.0 से 4.22.0 से पहले। camel-google-storage उपभोक्ता (consumer) जब downloadFileName विकल्प सेट होता है, तो Google Cloud Storage ऑब्जेक्ट्स को स्थानीय फ़ाइल सिस्टम पर डाउनलोड करता है। यह विकल्प एक फ़ोल्डर या फ़ाइल नाम के रूप में प्रलेखित है, और जब इसके मान में कोई expression token नहीं होता, तो उपभोक्ता उसमें ऑब्जेक्ट नाम जोड़कर स्थानीय गंतव्य बनाता है: evaluateFileExpression Exchange file-name हेडर को रिमोट ऑब्जेक्ट नाम पर सेट करता है और downloadFileName + "/${file:name}" का मूल्यांकन करता है। ${file:name} टोकन file-name हेडर को यथावत (verbatim) लौटाता है, ${file:onlyname} के विपरीत, जो उस पर FileUtil.stripPath लागू करता है। परिणामी स्ट्रिंग को बिना किसी lexical normalization और बिना यह जाँचे कि गंतव्य कॉन्फ़िगर किए गए निर्देशिका के अंदर ही रहा, सीधे new File(result) और blob.downloadTo(file.toPath()) को पास कर दिया गया। ऑब्जेक्ट नाम route-controlled डेटा नहीं है: उपभोक्ता बकेट की सूची बनाता है, लौटाए गए प्रत्येक blob पर पुनरावृत्ति करता है, और blob.getBlobId().getName() से प्रति ऑब्जेक्ट एक exchange यथावत बनाता है, और filter विकल्प जो उन नामों को प्रतिबंधित कर सकता है, जब तक स्पष्ट रूप से सेट न किया गया हो, बिल्कुल लागू नहीं होता। Google Cloud Storage ऑब्जेक्ट नाम अपारदर्शी UTF-8 कुंजियाँ हैं जिन्हें सेवा यथावत लिखे अनुसार संग्रहीत और सूचीबद्ध करती है, बिना किसी server-side canonicalization के, और forward slash केवल pseudo-directories के लिए प्रदर्शन परंपरा है, इसलिए parent-directory segments वाली कुंजी round-tripping के दौरान यथावत बनी रहती है। इसलिए ऐसे segments वाला ऑब्जेक्ट नाम कॉन्फ़िगर किए गए downloadFileName निर्देशिका के बाहर के स्थान पर resolve होता है, जिससे उपभोग किए गए बकेट में मौजूद नामों को प्रभावित करने में सक्षम कोई भी व्यक्ति Camel को अपनी पसंद के स्थान पर फ़ाइल बनाने या overwrite करने का कारण बना सकता है, Camel प्रक्रिया के विशेषाधिकारों के साथ। प्रक्रिया किस पर लिख सकती है, इसके आधार पर, download directory के बाहर किसी फ़ाइल को overwrite करना उस फ़ाइल की अखंडता के नुकसान से आगे बढ़कर और अधिक गंभीर हो सकता है। downloadFileName विकल्प एक सामान्य consumer पैरामीटर है और यह कोई security marker नहीं रखता, इसलिए उपयोगकर्ताओं को यह संकेत नहीं मिलता कि इसका मान containment boundary के रूप में लागू नहीं किया जा रहा है। यह दोष केवल consumer में है; producer में download-to-file sink नहीं है। Camel के अन्य फ़ाइल-डाउनलोड consumer - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files और Azure Storage डाउनलोड पथ - पहले से ही path-segment boundary check का उपयोग करके अपने स्थानीय डाउनलोड को कॉन्फ़िगर किए गए निर्देशिका तक सीमित करते थे; camel-google-storage उस कार्य द्वारा कवर न किया गया शेष object-store download sink था। उपयोगकर्ताओं को संस्करण 4.22.0 में अपग्रेड करने की अनुशंसा की जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.14.x LTS रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.14.9 में अपग्रेड करने का सुझाव दिया जाता है। यदि उपयोगकर्ता 4.18.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.18.4 में अपग्रेड करने का सुझाव दिया जाता है। ऐसे डिप्लॉयमेंट के लिए जो तुरंत अपग्रेड नहीं कर सकते, filter विकल्प को एक regular expression पर सेट करें जो केवल सरल single-segment ऑब्जेक्ट नाम स्वीकार करता है, ताकि exchange बनने से पहले path separator या parent-directory segment वाला कोई भी नाम बाहर रखा जाए; ध्यान दें कि विकल्प को सेट न छोड़ने पर कोई भी फ़िल्टरिंग लागू नहीं होती, और expression पूरे ऑब्जेक्ट नाम के विरुद्ध मिलान किया जाता है। वैकल्पिक रूप से, downloadFileName को एक स्पष्ट expression दें जो रिमोट पथ को आगे नहीं ले जाता, उदाहरण के लिए implicit ${file:name} के बजाय ${file:onlyname} पर बनाया गया expression, यह ध्यान में रखते हुए कि expression युक्त downloadFileName को route-author-controlled माना जाता है और fix में जोड़े गए containment check द्वारा कवर नहीं किया जाता। Defence in depth के रूप में, किसी भी externally writable bucket में ऑब्जेक्ट नामों को अविश्वसनीय इनपुट मानें और उनसे स्थानीय फ़ाइल सिस्टम पथ न बनाएं।