Nix इकोसिस्टम को हैक करना

• शोधकर्ता ने Nixpkgs की एक vulnerability खोजी और साझा किया कि कैसे इसके जरिए पूरे Nix इकोसिस्टम में malicious code inject किया जा सकता था
• GitHub Actions के pull_request_target trigger के माध्यम से यह समझाया गया कि external contributor PRs में भी sensitive permissions और secrets उजागर होने का संरचनात्मक जोखिम है
• वास्तव में editorconfig-checker और code owners validation jobs में command injection और symbolic link के उपयोग से privilege escalation संभव होने का प्रमाण दिया गया
• खोज के तुरंत बाद Nixpkgs maintainers ने तेजी से vulnerability को patch किया, vulnerable workflows को disable किया और permission operations की दोबारा समीक्षा की
• यह जोर दिया गया कि संगठन की CI/CD infrastructure में untrusted data और sensitive operations को अलग रखना, least privilege देना, और policies को मजबूत करना बहुत महत्वपूर्ण है

---

पूरे Nix इकोसिस्टम को हैक करना

परिचय और पृष्ठभूमि

• पिछले साल NixCon में शोधकर्ता और उनकी सहयोगी Lexi ने Nixpkgs की vulnerability पेश की
• इस खोजी गई vulnerability ने supply chain attack के जरिए पूरे Nix इकोसिस्टम में malicious code डालने की संभावना खोल दी
• vulnerability detection से लेकर report और remediation तक की तेज प्रतिक्रिया सिर्फ एक दिन में पूरी हुई
• शोधकर्ता इस साल NixCon में शामिल नहीं हो सके, इसलिए इस लेख में पूरी प्रक्रिया को विस्तार से संकलित किया गया है

GitHub Actions: एक संवेदनशील लक्ष्य

• GitHub Actions कोड repositories में विभिन्न automation tasks (CI/CD) को सपोर्ट करने वाली एक system है
• workflow files तक access permission होने पर code injection आसान हो जाता है, और इसी कारण यह supply chain attack का प्रमुख target बनता है
• workflow files YAML में लिखी जाती हैं, और चूंकि यह execution के लिए डिज़ाइन किया गया format नहीं है, इसलिए इनमें अप्रत्याशित security vulnerabilities मौजूद हो सकती हैं
• एक साधारण उदाहरण के तौर पर, code push होने पर command चलाने वाला workflow मौजूद होता है

खतरनाक pull_request_target trigger

• GitHub Actions में कई triggers होते हैं, जिनमें pull_request_target सामान्य pull_request से काफी अलग है
• pull_request_target को forked PRs से भी default रूप से read/write permissions और secrets access मिल जाता है
• इस trigger का गलत इस्तेमाल होने पर untrusted external data sensitive permissions के साथ जुड़ जाता है
• GitHub के official docs में भी इस जोखिम के बारे में स्पष्ट चेतावनी दी गई है
• शोधकर्ता ने Nixpkgs repository में pull_request_target का उपयोग करने वाले 14 workflows की जांच की

editorconfig-checker vulnerability

• सबसे पहले मिली vulnerable workflow का उद्देश्य editorconfig rules check करना था
• बदली गई files की list निकालने के बाद उसे xargs के जरिए editorconfig-checker को दिया जाता था
• अगर xargs command की security warning को नजरअंदाज किया जाए, तो malicious तरीके से बनाए गए filename (जैसे --help) को insert करने वाली vulnerability पैदा होती है
• इससे editorconfig-checker को मनमाने ढंग से manipulate किया जा सकता है, या आगे अतिरिक्त command execution की संभावना खुल सकती है (विस्तृत विश्लेषण के लिए और समीक्षा आवश्यक है)

codeowners-validator vulnerability: local file inclusion

• दूसरी और अधिक गंभीर vulnerability CODEOWNERS file validation workflow में मिली
• इस process में PR code को checkout करने के बाद codeowners-validator से file की जांच की जाती थी
• PR submitter OWNERS file को symbolic link से बदल सकता था, जिससे runner के अंदर किसी भी file को reference किया जा सकता था (जैसे action credentials)
• नतीजतन validation के दौरान उस file का content logs में प्रिंट हो जाता था, जिससे read/write permissions वाला GitHub token उजागर हो जाता था
• यह token मिल जाने पर Nixpkgs repository में सीधे push करना संभव हो जाता था

कार्रवाई और सबक

• vulnerability report के बाद Nixpkgs maintainer infinisil ने तुरंत प्रतिक्रिया दी
  • vulnerable workflows को अस्थायी रूप से disable किया गया
  • untrusted data और permissions के जुड़े हिस्सों को fix और अलग किया गया
  • security fix के बाद workflow names बदलकर branch targeting issue को कम किया गया
• मुख्य सबक
  • untrusted data को secrets और sensitive tasks के साथ कभी न जोड़ें, या अधिकतम सावधानी बरतें
  • least privilege के सिद्धांत का पालन करें
  • GitHub Actions permissions से जुड़ी official guide को समझना आवश्यक है
• ऐसी vulnerability होने पर संगठन का administrator policy के जरिए Actions को एक साथ disable कर सकता है (इसकी setup method भी दी गई है)

निष्कर्ष

• शोधकर्ता ने एक ही दिन में पूरे Nix इकोसिस्टम को खतरे में डाल सकने वाली vulnerability खोजी, रिपोर्ट की और fix में भाग लिया
• इससे GitHub Actions, खासकर pull_request_target के इस्तेमाल में विशेष सावधानी की जरूरत सामने आती है
• शोध में मदद करने वाले KITCTF के Intrigus और तेजी से प्रतिक्रिया देने वाले infinisil को धन्यवाद दिया गया
• रुचि रखने वाले पाठकों को presentation video और अतिरिक्त materials देखने की सलाह दी गई
• कुल मिलाकर, GitHub Actions security management की महत्ता और व्यावहारिक सीख पर जोर दिया गया

[GN⁺]

Hacker News की राय

• मुझे लगता है कि pull_request_target मूल रूप से security के लिहाज़ से कमजोर है, और GitHub को यह feature पूरी तरह हटा देना चाहिए। आम तौर पर कहा जाता है कि pull_request_target को सुरक्षित तरीके से इस्तेमाल करना हो तो branch द्वारा नियंत्रित code को job के दौरान चलाना नहीं चाहिए, लेकिन व्यवहार में argument injection या local file inclusion जैसी वजहों से attack surface इससे कहीं बड़ा हो जाता है। अभी इसके वैध use case ज़्यादातर third-party PR पर auto-labeling या auto-commenting तक सीमित हैं। ऐसे कामों के लिए repository पर by default write permission देने की ज़रूरत नहीं होनी चाहिए। GitHub को ऐसे कामों के लिए केवल उसी task तक सीमित token जारी करना चाहिए। इसलिए मैं zizmor में pull_request_target जैसे खतरनाक triggers के इस्तेमाल पर हमेशा flag लगाता हूँ, देखें zizmor dangerous triggers

  • मैं भी सहमत हूँ, लेकिन जब कोई organization forks की अनुमति नहीं देती, तब इसका एक use case बनता है। कुछ tools merge को GitHub के बाहर handle करते हैं, और ऐसे में ऐसे PR बन जाते हैं जिनका merge clean नहीं होता, इसलिए pull_request workflow trigger नहीं होता। उस स्थिति में pull_request_target practically एकमात्र विकल्प रह जाता है। बेहतर होता कि GitHub non-clean-merge PR पर भी workflow चलाने की कोई setting देता, जो by default disabled रहती और सिर्फ linter जैसी चीज़ों के लिए उपयोग होती। तब तक इस limitation की वजह से सिर्फ pull_request_target पर निर्भर रहना पड़ना दुर्भाग्यपूर्ण है। वैसे, ऐसे external tool का उपयोग करते समय अगर GitHub पर manual merge कर दिया जाए तो पूरा flow टूट जाता है, इसलिए manual merge बिल्कुल नहीं करना चाहिए
  • private repo में हम pull_request_target दो कारणों से इस्तेमाल करते हैं। पहला, workflow हमेशा main के आधार पर चलता है, इसलिए unvalidated test code को रोका जा सकता है। दूसरा, workflow के अंदर JWT के sub claim में job_workflow_ref निर्णायक रूप से मिलता है, जिससे OIDC-आधारित systems में fine-grained access control संभव होता है
  • GitHub के विवरण के अनुसार pull_request_target PR के base context में चलता है, इसलिए malicious code repository या secrets चुरा नहीं सकता। लेकिन वास्तव में secrets leak करना कितना आसान है, यह जानने के बाद यह बात कुछ हास्यास्पद लगती है
  • यह attack surface लगभग एक साल से unresolved है। पहले एक घटना हुई थी जिसमें एक Python package shellshock-जैसे code वाले malicious branch name का शिकार हुआ था। उस समय vulnerable variables और attack method को pentester के नज़रिए से इस ब्लॉग में अच्छी तरह समझाया गया था

• अगर Nix team ने मेरे प्रस्तावित RFC के अनुसार signed commits/reviews से अलग independently signed reproducible builds लागू किए होते, तो इस तरह के last-mile supply-chain attack संभव नहीं होते। आखिरकार NixPkgs चाहता है कि कोई भी आसानी से edit कर सके, और उसे डर है कि security पर ज़ोर देने की कोशिश से volunteers दूर हो जाएंगे, क्योंकि उसका फ़ोकस hobbyist distro पर है। यह ठीक है, लेकिन तब लोगों को यह बात साफ़-साफ़ बतानी चाहिए, और अगर सचमुच कीमती चीज़ों की सुरक्षा करनी है तो Nix को security-critical environments में इस्तेमाल या recommend करना बंद कर देना चाहिए। किसी चीज़ की रक्षा करने वाला OS हर बदलाव पर कठोर two-party hardware signing की मांग करे, और किसी एक मशीन या एक व्यक्ति पर trust नहीं छोड़े। इसी वजह से मैंने Stagex बनाया Stagex लिंक Codeberg लिंक

  • पहले यह स्पष्ट कर दूँ कि यह official stance नहीं है, लेकिन nixpkgs में security सुधारने में योगदान देने वाले व्यक्ति के रूप में मैं अपनी राय दे रहा हूँ। शायद आप RFC 0100 "Sign Commits" की बात कर रहे हैं(लिंक)। RFC चर्चा में बताया गया सबसे बड़ा अवरोध यह है कि mobile devices पर commit signing का support नहीं है। mobile tooling विकसित करने तक की क्षमता nixpkgs के पास नहीं है। मैं व्यक्तिगत रूप से commits sign करने और provenance बढ़ाने के पक्ष में हूँ, लेकिन अभी unsigned commit या untrusted key से भी push किया जा सकता है। Stagex जैसे security-focused project के लिए यह security layer स्वाभाविक है। लेकिन nixpkgs की trust philosophy अलग है। मैं ऐसी security policy से सहमत नहीं हूँ जो volunteers को भगा दे, इसलिए जिज्ञासा है कि nixpkgs में वास्तव में इस तरह की functionality का कितना उपयोग होता है। nixpkgs सिर्फ hobby distro नहीं है; बड़ी कंपनियाँ भी इसे वास्तव में काफी उपयोग करती हैं—NixCon 2025 sponsor list देख लें। और security features का अधिक adoption निश्चित रूप से सकारात्मक है, भविष्य में हालात बदल भी सकते हैं। लेकिन अभी nixpkgs में commit signing अनिवार्य करना मुझे अत्यधिक नुकसानदेह लगता है। साथ ही, “independent signed reproducible builds” वाला PR मैंने शायद नहीं देखा; nixpkgs जैसी scale पर third party के लिए ऐसी infrastructure बनाना बहुत बड़ा काम है। फिर भी NixOS लगभग पूरी तरह reproducible builds की दिशा में काम कर रहा हैstatus लिंक, और काफ़ी करीब है, हालांकि अभी 100% नहीं। निष्कर्षतः signed commits बेहतर security में मदद करेंगे, लेकिन nixpkgs के लिए उनके नकारात्मक प्रभाव भी बड़े हैं, इसलिए फिलहाल यह कठिन है। Stagex की two-party hardware signing पद्धति रोचक लगती है, अगर समझाएँ तो अच्छा होगा। अंत में, Stagex पर किया गया काम उत्पादक और दिलचस्प है, यह मैं मानता हूँ, बस कुछ गलतफहमियाँ दूर करना चाहता था
  • Stagex सचमुच प्रभावशाली है, लिंक साझा करने के लिए धन्यवाद
  • मैं बस समर्थन जताना चाहता हूँ, यह वाकई बहुत दिलचस्प project है
  • मुझे Stagex के बारे में आज पहली बार पता चला, और इस thread में यह सबसे दिलचस्प खोज रही
  • वाह... हैरानी हो रही है कि जो मैं लंबे समय से करना चाहता था, वह किसी ने पहले ही कर दिया

• मैंने परंपरागत रूप से computer systems design किए हैं, इसलिए यह देखना बहुत चौंकाने वाला है कि आज के workflows अब भी bearer token—यहाँ तक कि short-lived token—उन programs को दे देते हैं जिन पर उन्हें trust करना पड़ता है। अगर GitHub Actions framework केवल privileged Unix socket या ssh-agent access देता, तो ऐसे vulnerabilities का दुरुपयोग करना कहीं मुश्किल होता

  • पूरी तरह सहमत। bearer token की जगह signature-based scheme होनी चाहिए, और अगर private key को सीधे expose कर दिया जाए तो वह व्यावहारिक रूप से bearer token जैसा ही है। यही भूमिका signing agent निभाता है। GitHub API भले HTTP-आधारित हो, लेकिन mutual TLS और signing agent भर से भी काम चल सकता है
  • SPIFFE standard कुछ ऐसा ही काम करता है। लेकिन कोई इसका उपयोग नहीं करता; मुझे लगता है कि पूरी industry सुरक्षा को गंभीरता से नहीं लेती

• pull/merge requests के लिए CI/CD actions सचमुच एक दुःस्वप्न हैं। जब developers test या verification steps लिखते हैं, तो वे आमतौर पर यह मानकर लिखते हैं कि “मेरा code मेरे GitHub/GitLab account context में चलेगा।” यह उनके अपने या teammates के commits के लिए ठीक है, लेकिन PR में CI/CD pipeline untrusted code चलाती है। इस अंतर को हर समय ठीक-ठीक समझते रहना कठिन है। साधारण tests या linter चलाने तक तो ठीक है, लेकिन जैसे ही infrastructure integration की ज़रूरत पड़ती है और ज़्यादा permissions चाहिए होती हैं, चीज़ें जल्दी खतरनाक हो जाती हैं

  • समस्या यह नहीं है कि CI/CD PR से trigger होता है, बल्कि यह है कि GitHub ने लगभग एक जैसे दो triggers दिए हैं—pull_request और pull_request_target। इनमें से एक (pull_request) आम तौर पर लगभग सुरक्षित है, जब तक उसे जानबूझकर गलत न इस्तेमाल किया जाए; जबकि दूसरा (pull_request_target) लगभग कभी सुरक्षित ढंग से उपयोग नहीं किया जा सकता। इससे भी बड़ी समस्या यह है that GitHub ने PR पर label लगाना, auto-comment करना जैसे सामान्य काम भी केवल इसी खतरनाक trigger (pull_request_target) में संभव बनाए हैं, इसलिए लोग मजबूरी में अस्थिर विकल्प चुनते हैं। GitHub Actions का feature set गलती करवाने वाली संरचना जैसा है

• समय बीतने के साथ supply-chain attacks को लेकर मेरी चिंता बढ़ती जा रही है। यह सिर्फ “क्या इससे मेरी नौकरी जाएगी?” या “NixOS, CI/CD, Node वगैरह में कोई नया attack vector निकल आया” जैसी चिंता नहीं रह गई है; यह अब अधिक दार्शनिक चिंता बन गई है। जितना ज़्यादा हम depend करते हैं, उतनी ही ज़्यादा समस्याएँ सँभालनी पड़ती हैं। आराम से इस्तेमाल करने के लिए बनाई गई चीज़ें भी पहले से बहुत उलझ चुकी हैं—VSCode, Emacs, Nix, Vim, Firefox, JS, Node, और इनके सारे plugins व dependencies आपस में गुँथे हुए हैं। इसलिए शर्मिंदगी के साथ मैं धीरे-धीरे उस अजीब निष्कर्ष की ओर जा रहा हूँ कि control या security का थोड़ा-बहुत एहसास पाने के लिए शायद कागज़ और सिर्फ़ बेहद minimal, बहुत simple तकनीक ही इस्तेमाल करनी चाहिए। मुझे पता है यह अव्यावहारिक है, लेकिन इस complexity से अब सचमुच ऊब होने लगी है। अब तो complexity threshold भी महसूस होने लगा है

  • Emacs खुद सुरक्षित है और उसके सभी extensions का audit सीधे किया जा सकता है। समस्या तब होती है जब आप सभी extensions को Nix configuration की तरह blindly auto-update करते हैं। LLM का उपयोग करके obvious exploits को auto-detect और filter करने वाली automation की कल्पना की जा सकती है। enterprise-wide verification का अंतिम उत्तर Coq से सबकुछ formally verify करना होगा, लेकिन इसका मतलब है कि मौजूदा software का 99.999% फेंकना पड़ेगा

• xargs के man page में चेतावनी दी गई है कि “xargs को सुरक्षित रूप से उपयोग करना संभव नहीं है।” लेकिन यह security issue उस संदर्भ से अलग है जो यहाँ लागू हुआ। इस मामले में अंत में सिर्फ -- जोड़ देना पर्याप्त है

• “xargs को सुरक्षित रूप से उपयोग नहीं किया जा सकता” वाली बात का अक्सर गलत अर्थ लगाया जाता है। उदाहरण के लिए, cat "$HOME/changed_files" | xargs -r editorconfig-checker -- की तरह चलाने पर यहाँ बताई गई खास समस्या से बचा जा सकता है

  • लेकिन यह कुछ वैसा ही है जैसे हर HTML value के लिए अलग से <div>{escapeHtml(value)}</div> लगाकर XSS रोकना। अगर हर जगह manually safe usage लागू करना पड़े, तो तरीका ही मूल रूप से गलत है
  • यह चेतावनी यहाँ की स्थिति पर ठीक-ठीक लागू नहीं होती, लेकिन इसका सामान्य अर्थ सही है। हर program -- जैसे argument separator को support नहीं करता, और xargs के ज़्यादातर उपयोग argument injection के प्रति संवेदनशील होते हैं। दूसरे शब्दों में, हर command execution मूल रूप से risky है। यह xargs की गलती नहीं, बल्कि वह वास्तविकता है जिसमें tools अलग-अलग privilege contexts में बार-बार उपयोग किए जाते हैं

• उस लेख में इससे भी व्यापक असर वाला एक गंभीर loophole है: PR code में OWNERS file को symlink में बदला जा सकता है ताकि GitHub Actions credential file जैसे किसी भी arbitrary file को expose किया जा सके। चूँकि git softlink commit को support करता है, लगभग किसी भी workflow में यह जोखिम पैदा हो सकता है

  • बात सही है, लेकिन मेरी याद के अनुसार pull_request_target के दौरान credentials target repo, यानी merge destination repo के context के होते हैं। pull_request में चलाने पर credentials attacker-controlled source repo के होते हैं

• एकमात्र “अच्छी” खबर शायद यह है कि OpenBSD और NetBSD अभी भी package management के लिए CVS इस्तेमाल करते हैं, इसलिए यह vulnerability उन्हें प्रभावित नहीं करती। FreeBSD के बारे में निश्चित नहीं हूँ। एक तरह से security through obscurity जैसा मामला है। हालांकि लगता है वे projects भी git migration पर विचार कर रहे हैं, और OpenBSD शायद got(1)-आधारित रास्ते पर जाएगा

  • बात सही है, लेकिन यह git vulnerability नहीं बल्कि GitHub Actions vulnerability है। BSD projects अप्रत्यक्ष रूप से इसलिए सुरक्षित हैं क्योंकि GitHub CVS को support नहीं करता। अगर आप git या GitHub का उपयोग करें लेकिन GitHub Actions का नहीं, तो आप प्रभावित नहीं होंगे
  • यह git की नहीं, GitHub और खास तौर पर GitHub Actions की समस्या है
  • क्या वे contributions ईमेल से नहीं लेते? अगर ऐसा है तो spoofing attacks के लिए वे शायद और ज़्यादा जोखिम में हो सकते हैं