CVE-2026-11837: ansible.posix authorized_key स्थानीय विशेषाधिकार वृद्धि

ansible.posix.authorized_key Ansible मॉड्यूल में उपयोगकर्ता की ~/.ssh निर्देशिका और authorized_keys फ़ाइल पर सिम्लिंक-अनुसरण करने वाले chown (और सिम्लिंक-अनुसरण करने वाली फ़ाइल निर्माण) के माध्यम से स्थानीय विशेषाधिकार वृद्धि।

यह एक भेद्यता का विवरण है जिसे मैंने रिपोर्ट किया था और जिसे Red Hat Product Security (CNA) द्वारा CVE-2026-11837 निर्दिष्ट किया गया था। इसे यहाँ एक तकनीकी अभिलेख के रूप में प्रकाशित किया गया है, न कि नवीनता के दावे के रूप में: यह समस्या CVE-2024-9902 की सहोदर है, उस मॉड्यूल में जिसे पिछले सुधार ने कवर नहीं किया था।

आधिकारिक संदर्भ

• Red Hat CVE अभिलेख: https://access.redhat.com/security/cve/CVE-2026-11837
• Red Hat Bugzilla त्रुटि: https://bugzilla.redhat.com/show_bug.cgi?id=2487424
• प्रभावित मॉड्यूल स्रोत: https://github.com/ansible-collections/ansible.posix/blob/main/plugins/modules/authorized_key.py

Red Hat का प्रकाशित स्वीकृति वक्तव्य: "Red Hat इस मुद्दे की रिपोर्ट करने के लिए Valentino Paulon को धन्यवाद देना चाहेगा।"

सारांश

जब root के रूप में चलने वाली एक playbook किसी स्थानीय उपयोगकर्ता की कुंजियों को प्रबंधित करने के लिए ansible.posix.authorized_key का उपयोग करती है, तो मॉड्यूल का keyfile() सहायक फ़ंक्शन:

• उपयोगकर्ता की ~/.ssh निर्देशिका और ~/.ssh/authorized_keys के स्वामित्व को सादे os.chown से बदलता है (os.lchown नहीं), और
• कुंजी फ़ाइल को सादे open(..., "w") से बनाता है (कोई O_NOFOLLOW नहीं)।

डिफ़ॉल्ट follow=False के साथ, मॉड्यूल न तो सिम्लिंक का अनुसरण करके प्रतिस्थापित करता है और न ही उन्हें अस्वीकार करता है; यह सीधे पथ पर कार्य करता है, इसलिए कर्नेल उन सिम्लिंक का अनुसरण करता है जिन्हें विशेषाधिकार-रहित लक्ष्य उपयोगकर्ता ने अपनी स्वयं की ~/.ssh के अंदर पहले से तैनात किया है। इससे दो प्रिमिटिव प्राप्त होते हैं जो root-नियंत्रित पथ का स्वामित्व विशेषाधिकार-रहित उपयोगकर्ता को हस्तांतरित कर देते हैं, जो फिर root तक विशेषाधिकार वृद्धि करता है। दोनों की HEAD पर संग्रह के विरुद्ध अंत-से-अंत तक प्रतिकृति की गई।

प्रभावित कोड और मूल कारण

keyfile() (plugins/modules/authorized_key.py), डिफ़ॉल्ट manage_dir=True, follow=False के साथ:

if manage_dir:
    if not os.path.exists(sshdir):          # os.path.exists FOLLOWS symlinks
        try:
            os.mkdir(sshdir, int('0700', 8))
        ...
    os.chown(sshdir, uid, gid)              # UNCONDITIONAL, plain chown, follows symlink
    os.chmod(sshdir, int('0700', 8))        # follows symlink

if not os.path.exists(keysfile):           # follows symlink
    ...
    f = open(keysfile, "w")                # plain open(), no O_NOFOLLOW, follows symlink
    ...
try:
    os.chown(keysfile, uid, gid)           # UNCONDITIONAL, plain chown, follows symlink
    os.chmod(keysfile, int('0600', 8))     # follows symlink
except OSError:
    pass

sshdir और keysfile लक्ष्य उपयोगकर्ता के passwd होम से प्राप्त होते हैं (pwd.getpwnam(user).pw_dir), एक ऐसी निर्देशिका जिसका स्वामित्व और नियंत्रण विशेषाधिकार-रहित लक्ष्य उपयोगकर्ता के पास होता है। follow पैरामीटर (डिफ़ॉल्ट False) केवल यह चुनता है कि पथ पर os.path.realpath() लागू किया जाए या नहीं; दोनों ही स्थितियों में न तो कोई os.path.islink जाँच होती है, न O_NOFOLLOW open, न os.lchown, और न ही किसी पहले से मौजूद सिम्लिंक का unlink-और-प्रतिस्थापन। कोई विशेषाधिकार-परित्याग (seteuid/setfsuid) नहीं किया जाता; सब कुछ root के रूप में चलता है।

दोनों os.chown कॉल बिना किसी शर्त के चलते हैं, if not os.path.exists(...) गार्डों के बाहर, इसलिए वे निर्देशिका/फ़ाइल के पहले से मौजूद होने या न होने पर भी सक्रिय होते हैं। यही दोनों प्रिमिटिव को विश्वसनीय बनाता है।

दो प्रिमिटिव

दोनों की पुष्टि HEAD पर ansible.posix के साथ एक अस्थायी (throwaway) Linux VM पर अंत-से-अंत तक की गई। victim एक विशेषाधिकार-रहित स्थानीय उपयोगकर्ता है (uid 1000)। मॉड्यूल root के रूप में चलाया जाता है, ठीक उसी तरह जैसे किसी ऑपरेटर की playbook चलाती है। कैनरी (canaries) संवेदनशील root लक्ष्यों के स्थान पर उपयोग किए गए हैं।

वेक्टर 1: निर्देशिका सिम्लिंक (मौजूदा root-स्वामित्व वाली निर्देशिका का chown)

1. victim के रूप में: ln -s /root/AD_CANARY ~/.ssh (जिसमें /root/AD_CANARY एक मौजूदा root-स्वामित्व वाली निर्देशिका है)।
2. ऑपरेटर victim के लिए authorized_key कार्य चलाता है।
3. अवलोकन: /root/AD_CANARY का स्वामित्व root:root से बदलकर victim:victim हो गया। os.chown(sshdir, ...) कॉल ने ~/.ssh सिम्लिंक का अनुसरण किया और एक root-स्वामित्व वाली निर्देशिका विशेषाधिकार-रहित उपयोगकर्ता को सौंप दी।

वेक्टर 2: लटकता हुआ (dangling) फ़ाइल सिम्लिंक (नई root-पथ फ़ाइल का निर्माण + chown)

1. victim के रूप में (~/.ssh एक सामान्य निर्देशिका होने पर): ln -s /root/AF_CANARY ~/.ssh/authorized_keys (लक्ष्य मौजूद नहीं है)।
2. ऑपरेटर victim के लिए authorized_key कार्य चलाता है।
3. अवलोकन: /root/AF_CANARY बनाई गई, स्वामित्व victim:victim, मोड 0600। open(keysfile, "w") ने सिम्लिंक के माध्यम से लक्ष्य बनाया और os.chown(keysfile, ...) ने उसे सौंप दिया।

दोनों ही मामलों में विशेषाधिकार-रहित उपयोगकर्ता अंततः एक root-नियंत्रित पथ का स्वामित्व प्राप्त कर लेता है। लिंक को /etc के अंतर्गत किसी निर्देशिका (वेक्टर 1) या /etc/cron.d/ या /etc/sudoers.d/ के अंतर्गत किसी नई फ़ाइल (वेक्टर 2) की ओर इंगित करने से मानक अनुवर्ती चरण द्वारा root प्राप्त होता है, जिसमें उपयोगकर्ता, अब स्वामी होने के नाते, लक्ष्य को पुनः लिखता है।

CVE-2024-9902 से संबंध

यह CVE-2024-9902 की सहोदर है (ansible-core में user मॉड्यूल का generate_ssh_key), जिसने उसी सिम्लिंक-अनुसरण श्रेणी को संबोधित किया था। authorized_key अलग ansible.posix संग्रह में स्थित है और उस सुधार से परिवर्तित नहीं हुआ था; सिम्लिंक-अनुसरण करने वाला chown/निर्माण पैटर्न अभी भी मौजूद और असंरक्षित था। इसे पिछले सुधार द्वारा न पहुँचे गए मॉड्यूल में उसी स्वीकृत श्रेणी के रूप में रिपोर्ट किया गया है, न कि किसी नए मूल कारण के रूप में।

प्रभाव और स्पष्ट पूर्व-शर्तें

• Ansible द्वारा प्रबंधित होस्ट पर विशेषाधिकार-रहित स्थानीय उपयोगकर्ता से root तक विशेषाधिकार वृद्धि।
• यह ऑपरेटर द्वारा victim के खाते को लक्षित करने वाला ansible.posix.authorized_key कार्य चलाने पर निर्भर है (इस मॉड्यूल का सामान्य उपयोग)। स्थानीय उपयोगकर्ता सिम्लिंक को अपनी स्वयं की ~/.ssh में पहले से तैनात करता है; वे playbook नहीं चलाते। यह ऑपरेटर-ट्रिगर है: CVE-2024-9902 के समान ट्रिगर मॉडल, जिसे Red Hat ने "अविश्वसनीय खातों के विरुद्ध न चलाएँ" शमन के साथ स्वीकार किया था। पूर्व-शर्त को स्पष्ट रूप से बताया गया है, न कि स्व-ट्रिगर के रूप में वर्गीकृत किया गया है।

सुझाया गया सुधार

• कुंजी फ़ाइल को सिम्लिंक का अनुसरण किए बिना और अनन्य रूप से बनाएँ: os.open(keysfile, os.O_WRONLY | os.O_CREAT | os.O_EXCL | os.O_NOFOLLOW, 0o600) और डिस्क्रिप्टर पर कार्य करें; यदि sshdir या keysfile सिम्लिंक है तो उसे अस्वीकार करें (या follow=False docstring अनुबंध के अनुसार unlink-और-प्रतिस्थापित करें)।
• os.chown(...) को os.lchown से बदलें, या सुरक्षित रूप से खोले गए डिस्क्रिप्टर पर os.fchown से, और इसी प्रकार os.chmod के स्थान पर os.fchmod उपयोग करें, ताकि स्वामित्व और अनुमतियों को लिंक के माध्यम से पुनर्निर्देशित न किया जा सके।
• बिना शर्त वाले chown/chmod को इस प्रकार नियंत्रित करें कि वे केवल उसी पथ पर लागू हों जिसे मॉड्यूल ने स्वयं अभी सुरक्षित रूप से बनाया है, न कि किसी पहले से मौजूद (संभवतः सिम्लिंक वाले) पथ पर।

प्रकटीकरण समयरेखा

लाइसेंस

MIT. देखें LICENSE।