GitHub पर डिलीट या प्राइवेट Repo डेटा तक कोई भी पहुंच सकता है

• GitHub में डिलीट किए गए forks, डिलीट किए गए repositories, और यहां तक कि private repositories के डेटा तक भी पहुंचा जा सकता है
• GitHub इस बारे में जानता है और यह जानबूझकर किया गया design है
  • क्योंकि यह GitHub इस्तेमाल करने वाले हर organization के लिए एक बड़ा attack vector बनता है, इसलिए "Cross Fork Object Reference (CFOR)" नाम का नया शब्द पेश किया गया है
• CFOR vulnerability तब होती है जब एक repository fork किसी दूसरे fork के महत्वपूर्ण डेटा तक पहुंच सकता है, जिसमें private और deleted forks का डेटा भी शामिल है

डिलीट किए गए fork के डेटा तक पहुंचना

• GitHub में एक सामान्य workflow पर विचार करें: आप एक public repository को fork करते हैं, अपने fork में code commit करते हैं, और फिर उस fork को डिलीट कर देते हैं
• fork में commit किया गया code अब भी accessible रहता है, और हमेशा accessible रह सकता है
• आपको लग सकता है कि commit hash जानना जरूरी होने से यह सुरक्षित है, लेकिन hash खोजे जा सकते हैं
• deleted forks से डेटा ढूंढना काफी बार होता है

डिलीट किए गए repository के डेटा तक पहुंचना

• एक स्थिति मानें जहां GitHub पर एक public repository है, कोई user उसे fork करता है, fork के बाद कुछ डेटा commit करता है, और फिर पूरी repository को डिलीट कर देता है
• fork के बाद commit किया गया code अब भी accessible रहता है
• GitHub repositories और forks को एक repository network में store करता है, जहां मूल "upstream" repository root node की भूमिका निभाती है
• अगर fork की गई public "upstream" repository "डिलीट" हो जाती है, तो GitHub root node की भूमिका downstream forks में से किसी एक को दे देता है
• लेकिन "upstream" repository के सभी commits अब भी मौजूद रहते हैं और सभी forks के जरिए accessible होते हैं

private repository के डेटा तक पहुंचना

• GitHub पर किसी नए tool को open source करने वाले सामान्य workflow पर विचार करें
• आप एक private repository बनाते हैं जिसे बाद में public करना है, उस repository का एक private internal version (fork के जरिए) बनाते हैं, उसमें उन features के लिए अतिरिक्त code commit करते हैं जिन्हें public नहीं करना है, फिर "upstream" repository को public कर देते हैं और fork को private ही रखते हैं
• private features और उनसे जुड़ा code (step 2 में) public repository से access किया जा सकता है
• "upstream" repository को public करने के बाद private fork में किए गए commits दिखाई नहीं देते

वास्तव में डेटा तक पहुंच कैसे मिलती है?

• commits को सीधे access करके
• GitHub के repository network में destructive actions (जैसे ऊपर बताए गए 3 scenarios) standard GitHub UI और सामान्य git operations से commit data के references हटा देते हैं
• लेकिन यह डेटा अब भी मौजूद रहता है और (अगर commit hash पता हो) access किया जा सकता है
• commit hash एक SHA-1 value होती है, और अगर किसी user को उस specific commit का SHA-1 commit hash पता हो जिसे वह देखना चाहता है, तो वह https://github.com/<user/org>/…; endpoint पर जाकर सीधे उस commit तक पहुंच सकता है
• commit hashes को GitHub UI के जरिए brute-force भी किया जा सकता है
• GitHub के public events API endpoint के जरिए commit hashes query भी किए जा सकते हैं

GitHub की policy

• हाल ही में यह निष्कर्ष GitHub के VDP program के जरिए submit किया गया, और GitHub ने स्पष्ट किया कि repositories का इस तरह काम करना design के मुताबिक है
• documentation की समीक्षा करने पर यह भी दिखता है कि ऊपर बताए गए cases में users को क्या expect करना चाहिए, इसे GitHub ने स्पष्ट रूप से document किया है

प्रभाव

• जब तक एक भी fork मौजूद है, उस repository network के सभी commits (चाहे "upstream" repository के हों या "downstream" forks के) हमेशा के लिए मौजूद रहेंगे
• GitHub की repository architecture इस design flaw को अनिवार्य बनाती है, और अधिकांश GitHub users वास्तव में repository network कैसे काम करता है, यह नहीं समझते, इसलिए वे कम सुरक्षित हो सकते हैं
• जैसे-जैसे secret scanning आगे बढ़ेगी और repository network के सभी commits को scan करना संभव होगा, वैसे-वैसे आपको ऐसे secrets के बारे में alert मिल सकता है जो आपके अपने नहीं हैं
• ये 3 scenarios चौंकाने वाले हैं, लेकिन ये उन सभी तरीकों को कवर नहीं करते जिनसे GitHub repositories में deleted data store रह सकता है

GN⁺ की राय

• यह लेख GitHub इस्तेमाल करने वाली organizations के लिए एक महत्वपूर्ण security issue उठाता है। डिलीट या private की गई repositories का डेटा अब भी accessible होना चौंकाने वाला है। यह GitHub की repository network architecture से जुड़ा एक मूलभूत design flaw लगता है
• developers को इस समस्या के बारे में जागरूक होना चाहिए और GitHub पर महत्वपूर्ण data या secrets commit करते समय सावधानी बरतनी चाहिए। एक बार public repository में push हो जाने के बाद, वह हमेशा के लिए accessible रह सकता है। अगर कोई महत्वपूर्ण secret लीक हो जाए, तो उसका पूरा समाधान केवल key rotation से ही संभव हो सकता है
• GitHub इस issue को transparency के साथ disclose और document करता है, लेकिन अधिकांश users repository network के काम करने के तरीके को पूरी तरह नहीं समझेंगे। GitHub को इस मुद्दे पर awareness बढ़ाने और users को educate करने के लिए और अधिक प्रयास करने चाहिए
• दूसरे version control systems में भी इसी तरह की समस्याएं हो सकती हैं। developers और organizations को महत्वपूर्ण data manage करते समय अपने tools की architecture और limitations को अच्छी तरह समझना चाहिए
• महत्वपूर्ण data leakage रोकने के लिए strict access control, least privilege principle, नियमित secret scanning और monitoring जैसी multi-layered security measures की आवश्यकता है। सबसे बढ़कर, developers में मजबूत security awareness होना जरूरी है

[GN⁺]

Hacker News राय

• 2018 में इसे HackerOne पर रिपोर्ट किया गया था, लेकिन GitHub ने इसे इच्छित व्यवहार बताया और ठीक नहीं किया। निष्कर्ष: personal fork की जगह repository को कॉपी करके इस्तेमाल करें
• GitHub हर चीज़ को public और immutable बनाने को लेकर जुनूनी है। उदाहरण के लिए, किसी comment को delete करने के लिए repository owner को ईमेल से अपना वास्तविक ID भेजना पड़ता है
• "private" फीचर की इन समस्याओं के बारे में users को जानने की ज़रूरत नहीं होनी चाहिए, और GitHub का इसे bug नहीं बल्कि feature मानना security के प्रति उदासीनता दिखाता है। private repository को "unlisted" repository कहना अधिक उपयुक्त होगा
• private repository और private fork का उपयोग करते समय अगर repository को public में बदला जाए, तो fork भी public हो जाता है। GitHub भले इसे इच्छित व्यवहार बताए, लेकिन repository और fork को एक साथ public करने के लिए स्पष्ट मजबूरी होनी चाहिए
• यह व्यवहार dark pattern जैसा लगता है, और लोगों की आजीविका दांव पर होने के बावजूद GitHub को परवाह नहीं है। ऐसा इसलिए है क्योंकि plausible deniability और अस्पष्ट terms of service, reputational damage से अधिक मूल्यवान माने जाते हैं
• इस समस्या को कम करके आंकने वाली टिप्पणियों पर हैरानी है। लंबे समय से GitHub इस्तेमाल करने के बावजूद मैंने ऐसे परिणाम की अपेक्षा नहीं की थी और असहजता महसूस होती है। लेख खुद पढ़ने की सलाह है
• यह समस्या नई नहीं है। बहुत से लोग पहले भी इसे खोज चुके हैं
• GitHub के OSPO में public forks के private mirror को बनाए रखने के लिए एक open source GitHub App विकसित किया जा रहा है। इसका beta release इस सप्ताह निर्धारित है
• GitHub Events archive जिस तरह vulnerable repositories के SHA1 hash को उजागर करता है, वही असली vulnerability है। पूरे network में खोजकर deleted private repositories तक पहुंचा जा सकता है
• समस्या यह है कि private data public data पर निर्भर हो सकता है। उदाहरण के लिए, अगर कोई private commit public commit C पर निर्भर करता है, तो public repository से C हटाए जाने पर GitHub को उसे बनाए रखना चाहिए। वरना private commit टूट जाएगा
• GitHub पर submit किए जाने के बाद सभी commits हमेशा के लिए जीवित रहते हैं, और जो commit एक बार public हो जाए, वह हमेशा commit hash के जरिए सुलभ रहता है