0xmrma/cve-2026-14361Consul Template का writeToFile सहायक, ऑपरेटर द्वारा आपूर्ति किए गए गंतव्य को सीधे खोलता था और लिंक किए गए पथ घटकों का अनुसरण करता था, जिससे रेंडर किया गया आउटपुट इच्छित निर्देशिका से बाहर निकलकर किसी पहले से मौजूद फ़ाइल को अधिलेखित कर सकता था।
Consul Template का writeToFile हेल्पर ऑपरेटर-आपूर्ति किए गए गंतव्य को सीधे खोलता था और लिंक किए गए पथ घटकों का अनुसरण करता था, जिससे रेंडर किया गया आउटपुट इच्छित निर्देशिका से बाहर निकलकर किसी पूर्व-मौजूदा फ़ाइल को अधिलेखित कर सकता था।
मुझे यह समस्या HashiCorp Consul Template की समीक्षा करते समय मिली, जिसमें एक सीधा फाइलसिस्टम सुरक्षा प्रश्न ध्यान में था:
यदि writeToFile को ऐसा पथ मिलता है जो इच्छित निर्देशिका के अंदर प्रतीत होता है, तो क्या यह सत्यापित करता है कि फाइलसिस्टम वास्तव में डेटा कहाँ लिखेगा?
इस मामले में, उत्तर नहीं था।
writeToFile टेम्पलेट हेल्पर ने अंतिम उपयोगकर्ता-आपूर्ति पथ को os.Create() या os.OpenFile() के माध्यम से सीधे खोला।
वे ऑपरेशन गंतव्य पथ में पहले से मौजूद प्रतीकात्मक लिंक, डायरेक्टरी जंक्शन और समकक्ष फाइलसिस्टम पुनर्निर्देशन का अनुसरण करते थे।
इसका मतलब था कि पथ स्ट्रिंग ऑपरेटर के इच्छित रूट के अंतर्गत बनी रह सकती थी जबकि वास्तविक लेखन कहीं और होता था।
मेरे नियंत्रित प्रमाण-की-अवधारणा में, एक लिंक किए गए पैरेंट निर्देशिका ने रेंडर किए गए आउटपुट को इच्छित ट्री के बाहर पुनर्निर्देशित किया और एक पूर्व-मौजूदा लक्ष्य फ़ाइल को नष्ट कर दिया।
वह समस्या CVE-2026-14361 बन गई।
HashiCorp बुलेटिन: HCSEC-2026-20
IBM बुलेटिन: CVE-2026-14361 security bulletin
CVE: CVE-2026-14361
इसमें ठीक हुआ: 0.42.1
photo0
ऑपरेटर-आपूर्ति किया गया गंतव्य इच्छित रूट के अंदर दिखाई देता है -> हमलावर लिंक किए गए पैरेंट या अंतिम पथ घटक को पूर्व-स्थित करता है -> writeToFile पथ को सीधे खोलता है -> फाइलसिस्टम लेखन को इच्छित निर्देशिका के बाहर हल करता है -> रेंडर किया गया रहस्य पुनर्निर्देशित हो जाता है -> पूर्व-मौजूदा लक्ष्य अधिलेखित हो सकता है
Consul Template Consul और Vault जैसे स्रोतों से डेटा रेंडर करता है।
writeToFile हेल्पर एक टेम्पलेट को चयनित सामग्री को एक अलग स्थानीय फ़ाइल में लिखने देता है, साथ ही अनुरोधित स्वामी, समूह और अनुमति मोड लागू करता है।
HashiCorp का प्रलेखन विशेष रूप से PKI सामग्री के साथ हेल्पर को प्रदर्शित करता है:
private key -> writeToFile /my/path/to/cert.key
certificate authority -> writeToFile /my/path/to/cert.pem
certificate -> append to /my/path/to/cert.pem
यह इसे एक सामान्य आउटपुट हेल्पर से अधिक बनाता है।
इस सीमा को पार करने वाली सामग्री में शामिल हो सकते हैं:
महत्वपूर्ण प्रश्न यह नहीं था कि क्या writeToFile अनुरोधित फ़ाइलनाम बना सकता है।
वास्तविक प्रश्न यह था:
क्या प्रक्रिया ऑपरेटर के इच्छित फाइलसिस्टम स्थान पर लिखती है, या केवल उस ऑब्जेक्ट पर जिसे पथ open के समय हल करता है?
भेद्य संस्करणों में, इसने बाद वाले पर भरोसा किया।
लेखन हेल्पर उच्च-मूल्य वाली सुरक्षा सतहें हैं क्योंकि वे अनुप्रयोग डेटा से फाइलसिस्टम परिवर्तन में प्रवेश करती हैं।
दिलचस्प विफलताएँ अक्सर क्लासिक ../ ट्रैवर्सल नहीं होती हैं।
वे समाधान विफलताएँ हैं:
यह विशेष रूप से महत्वपूर्ण है जब प्रक्रिया हमलावर की तुलना में अधिक फाइलसिस्टम विशेषाधिकारों के साथ चलती है।
एक कम-विशेषाधिकार वाला स्थानीय हमलावर सीधे संवेदनशील फ़ाइल को अधिलेखित करने में सक्षम नहीं हो सकता है।
लेकिन यदि वे इच्छित लेखन निर्देशिका के अंतर्गत एक पथ घटक को प्रभावित कर सकते हैं, तो एक अधिक विशेषाधिकार प्राप्त Consul Template प्रक्रिया उनके लिए लेखन कर सकती है।
यही वह सीमा थी जिस पर मैंने ध्यान केंद्रित किया।
मैंने इसे एक सामान्य पथ ट्रैवर्सल समीक्षा के रूप में नहीं देखा।
आपूर्ति किए गए पथ को .. खंडों की आवश्यकता नहीं थी।
यह पूरे समय शाब्दिक रूप से इच्छित रूट के अंदर रह सकता था।
अधिक मजबूत प्रश्न यह था:
क्या संवेदनशील सामग्री लिखे जाने से पहले लिंक किए गए गंतव्य घटकों को अस्वीकार कर दिया जाता है?
वह प्रश्न दोनों के लिए मायने रखता है:
दूसरा मामला विशेष रूप से उपयोगी है क्योंकि लॉग और कॉन्फ़िगरेशन अभी भी अपेक्षित निर्देशिका के अंतर्गत एक निर्दोष-दिखने वाला पथ दिखाते हैं।
फाइलसिस्टम इसे कहीं और हल करता है।
मूल कारण लिंक-जागरूक सत्यापन के बिना प्रत्यक्ष पथ-आधारित फ़ाइल निर्माण था।
परीक्षण किए गए रिवीज़न पर, writeToFile() ने दो open पथों में से एक का चयन किया।
अपेंड मोड उपयोग करता था:
f, err = os.OpenFile(
path,
os.O_APPEND|os.O_WRONLY|os.O_CREATE,
perm,
)
सामान्य लेखन मोड उपयोग करता था:
dirPath := filepath.Dir(path)
if _, err := os.Stat(dirPath); err != nil {
err := os.MkdirAll(dirPath, os.ModePerm)
if err != nil {
return "", err
}
}
f, err = os.Create(path)
फ़ाइल खोले जाने से पहले किसी भी पथ ने लिंक किए गए गंतव्य घटकों को अस्वीकार नहीं किया।
यह मायने रखता है क्योंकि:
os.Create(path) मौजूदा फाइलसिस्टम पुनर्निर्देशन का अनुसरण करता है और हल की गई फ़ाइल को छोटा करता हैos.OpenFile(path, ...) अपेंड मोड के दौरान लिंक किए गए पथ घटकों का अनुसरण करता हैवही पथ-आधारित धारणा लेखन के बाद भी जारी रही।
स्वामित्व और अनुमतियाँ फिर से पथ का उपयोग करके लागू की गईं:
err = os.Chown(path, uid, gid)
err = os.Chmod(path, perm)
इसका मतलब था कि मेटाडेटा संचालन भी पहले से खुले फ़ाइल डिस्क्रिप्टर के बजाय एक परिवर्तनीय पथ नाम से बंधे थे।
क्योंकि हमलावर writeToFile चलने से पहले पुनर्निर्देशन तैयार कर सकता है।
मूल आक्रमण के लिए किसी संभाव्य दौड़ की आवश्यकता नहीं है।
अनुक्रम सीधा है:
writeToFile इसे सीधे खोलता हैयही पूरी भेद्यता है।
यह सत्य है कि ऑपरेटिंग सिस्टम सामान्यतः पथ-आधारित फ़ाइल खोलने के दौरान सिमलिंक का अनुसरण करते हैं।
इससे यह सुरक्षित अनुप्रयोग व्यवहार नहीं बन जाता।
सुरक्षा प्रश्न यह नहीं है:
"क्या Go ने प्रलेखित अनुसार व्यवहार किया?"
वास्तविक प्रश्न यह है:
क्या संवेदनशील रेंडर किए गए डेटा को लिखने वाले हेल्पर ने सत्यापित किया कि हल किया गया गंतव्य ऑपरेटर के इच्छित स्थान से मेल खाता है?
भेद्य संस्करणों में, उसने नहीं किया।
यह अंतर मायने रखता है क्योंकि Consul Template चल सकता है:
उस संदर्भ में हमलावर-स्थित फाइलसिस्टम पुनर्निर्देशन का अनुसरण करना एक वास्तविक विशेषाधिकार और विश्वास-सीमा समस्या पैदा करता है।
मैंने परीक्षण किए गए कमिट पर सटीक writeToFile व्यवहार के आसपास एक स्टैंडअलोन रिप्रोड्यूसर बनाया।
नियंत्रित सेटअप में उपयोग किया गया:
writeToFile को दी गई नियंत्रित गुप्त सामग्रीपुनरुत्पादन प्रवाह था: