फ़िलहाल नया software install न करना बेहतर हो सकता है

 (xeiaso.net)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • copy.fail के बाद Linux kernel vulnerability के बारे में अतिरिक्त घोषणाएँ की गई हैं
  • फिलहाल इसे ऐसा समय माना जा रहा है जब NPM supply chain attack से बड़ा नुकसान हो सकता है
  • distribution द्वारा दिए जाने वाले Linux kernel patch को अपवाद मानने की सिफारिश है
  • इसके अलावा लगभग एक हफ्ते तक नया software install रोक देना बेहतर है
  • पोस्ट प्रकाशित होने के बाद तथ्य या स्थिति बदल चुकी हो सकती है, इसलिए जो हिस्सा गलत या अस्पष्ट लगे उस पर निष्कर्ष निकालने से पहले संपर्क करने का नोट जोड़ा गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की राय

  • यह तो हमेशा से फूटने को तैयार एक दुःस्वप्न था। पैकेज बहुत ज़्यादा हैं, और उसी अनुपात में supply chain attack surface इतना विशाल हो गया है कि यह कभी न कभी सबके सामने फटना ही था
    लेकिन यह बहुत सुविधाजनक था। चेतावनी देने या नुकसान कम करने की कोशिश करने वालों को उन लोगों ने नज़रअंदाज़ कर दिया जिनके पास किसी और तरीके का अनुभव ही नहीं था, और "import antigravity" छोड़ देना बहुत कठिन था
    अब लगता है कि हम “कीमत चुकाने” वाले चरण में पहुँच गए हैं

    • एक कंपनी में हम सचमुच बहुत conservative तरीके से काम करते थे। सभी बाहरी components के version pin किए जाते थे, review के बिना update नहीं होते थे, और आम तौर पर उन्हें पर्याप्त stabilization period दिया जाता था
      compiler, kernel आदि समेत लगभग हर चीज़ source से build की जाती थी, और build server/infra को इंटरनेट तक बिल्कुल पहुँच नहीं थी, साथ ही changes लाने की एक तय प्रक्रिया थी। संबंधित CVE हर बार public होने पर review किए जाते थे ताकि यह तय किया जा सके कि वे हम पर लागू होते हैं या नहीं, और उन्हें कैसे mitigate या handle करना है
      बाद में जिस कंपनी में गया, वहाँ builds इंटरनेट तक पहुँचते थे, और नया version आते ही upgrade कर दिया जाता था। लोग इसे अच्छी practice मानते थे क्योंकि इससे latest bug fixes मिलते थे, और CVE review security team संभालती थी
      उसके बाद जिस startup में गया, वहाँ कई practices का मिश्रण था। कुछ चीज़ें बहुत अच्छी थीं, लेकिन CVE debt भी बड़ा था। उदाहरण के लिए, servers पर secure boot और encrypted disk लागू थे, और components के बीच communication security की समझ भी काफ़ी अच्छी थी
      हर किसी को लगता है कि वही सही कर रहा है। “बार-बार upgrade करने” वालों को यह समझाना लगभग असंभव है कि इससे नई समस्याएँ भी आ सकती हैं। उद्योग को बेहतर practices के एक पैकेज की ज़रूरत है, और व्यक्तिगत रूप से मुझे पहली कंपनी का dependency management ज़्यादा बेहतर लगता है। कुल मिलाकर वहाँ security practices अच्छी तरह स्थापित थीं और product भी सचमुच सुरक्षित था
    • Pandora’s box खोलने जैसा लगे तो भी, अगर इन सभी अनजान attack vectors को सामने लाने का net effect दुनिया भर की intelligence agencies के जमा किए हुए vulnerabilities के भंडार को खाली कर देना हो, तो?
      तब उपयोगी software सबका सब fuzzing test, property testing, और formal verification से गुज़र चुका होगा, और vulnerabilities ढूँढने वाले सभी लोगों को फिर से शून्य से शुरू करना पड़ेगा
      बेशक, यह मानना होगा कि इस बीच का वह खाली दौर हम झेल लें, जिसमें देश अपनी बची हुई क्षमताएँ अपने सबसे बुरे दुश्मनों पर फेंकते रहें। नहीं तो अंत में शायद हम एक-दूसरे को जानवरों की हड्डियों से ही मारेंगे
    • मैं वर्षों से capability-based security model चाहता रहा हूँ, और इस पर यहाँ बहस भी कर चुका हूँ। Capability एक object pointer जैसी चीज़ होती है, जिसके साथ संबंधित permissions जुड़ी होती हैं, कुछ Unix file descriptor की तरह
      OS स्तर पर, चलाए गए program को shell या जिस जगह से उसे चलाया गया है वहाँ से capability token मिलना चाहिए, और हर system call को पहला argument capability लेना चाहिए। इसलिए "open path /foo" की जगह open(cap, "/foo") होगा। यह capability fake filesystem, असली filesystem की कोई branch, network filesystem, या कुछ भी हो सकती है, और program को यह जानने की ज़रूरत नहीं होगी कि वह किस sandbox में रह रहा है
      Library/language स्तर पर भी, npm module जैसी third-party library import करते समय import के समय या call site पर capability पास करनी चाहिए। उस library को मेरे program address space के हर byte पर read/write access नहीं मिलनी चाहिए, और वह मेरे कंप्यूटर पर मेरी तरह कुछ भी करने में सक्षम नहीं होनी चाहिए। असली सवाल है: इस code का blast radius कहाँ तक है? अगर इस्तेमाल की गई library malicious या vulnerable हो, तो नुकसान की सीमा के बारे में हमारे पास एक तर्कसंगत default होना चाहिए। lib::add(1, 2) कॉल मेरे पूरे कंप्यूटर के persistent compromise में नहीं बदलनी चाहिए
      SeL4 लंबे समय से तेज़ और efficient OS-level capabilities देता आया है, और यह काम भी करता है। कई मामलों में यह Linux से तेज़ है, और transparent sandboxing, user-space drivers, inter-process communication, security improvement आदि के लिए बहुत उपयोगी है। Linux को SeL4 के ऊपर एक process की तरह भी चलाया जा सकता है। मैं ऐसा operating system चाहता हूँ जिसमें Linux desktop की सारी functionality हो, लेकिन वह SeL4 की तरह व्यवहार करे
      अफ़सोस, मुझे वैसी language-level capabilities वाली programming language नहीं दिखती जैसी मैं चाहता हूँ। Rust काफ़ी करीब है, लेकिन third-party crate को किसी भी unsafe code को call करने से रोकने का तरीका चाहिए। इसमें untrusted dependencies द्वारा बुलाया गया unsafe भी शामिल है। Rust के पुराने soundness bugs भी ठीक होने चाहिए, और capability-based standard library भी चाहिए। global open() / listen() जैसी चीज़ें गायब हो जानी चाहिएँ, और केवल openat() तथा OS के अन्य हिस्सों से मेल खाने वाले समकक्ष रूप होने चाहिएँ
      अगर LLM इसी तरह बेहतर होते रहे, तो कुछ साल में अगर किसी और ने यह पहले नहीं बनाया, तो मैं LLM से यह सब बनवाने की सोच रहा हूँ। आधुनिक desktop operating systems की security तो मज़ाक जैसी है
    • ज़्यादातर लोग सामान्यतः कुछ भी उठाकर मुँह में नहीं डालते। वे microbial culture का positive result आने तक इंतज़ार करके फिर उसे ठुकराते नहीं हैं
      Code के लिए भी hygiene culture चाहिए, और यह उन मानकों से बहुत अलग नहीं है जो ज़्यादातर संस्कृतियों ने भोजन के लिए विकसित किए हैं। यह भले ही ढीले-ढाले heuristics का मेल हो, लेकिन “छी” वाला एहसास अरबों लोगों की जान बचाता है
    • एक साल पहले मैंने कहा था कि जहाँ संभव हो, third-party चीज़ें लाने के बजाय ख़ुद code लिखना बेहतर है। उस समय LLM से gaps भरवाने का विचार तक लगभग विधर्म जैसा माना जाता था
      अब मैं dependency exposure पहले से कहीं ज़्यादा कम कर रहा हूँ, खासकर उन चीज़ों में जिन्हें कुछ सौ lines में implement किया जा सकता है। यह सचमुच एक paradigm shift है

  • “सॉफ़्टवेयर install करने से पहले एक हफ़्ता इंतज़ार करो” वाला तरीका काम नहीं करेगा। बस कुछ महीने पहले भी एक बड़े vulnerability set ने web को प्रभावित किया था, और वह time-delayed attack था जो एक महीने से ज़्यादा छिपा रहने के बाद execute हुआ
    अगर सब लोग एक हफ़्ता इंतज़ार करने लगें, तो attacker दो हफ़्ते इंतज़ार करेंगे। Cyber criminals को तुरंत exploit करने की ज़रूरत नहीं है, उन्हें बस किसी समय exploit कर लेना होता है। Typosquatting जैसी कई vulnerability categories पर भी इस तरीके का कोई असर नहीं पड़ेगा

    • लगता है लेखक का मतलब यह नहीं है कि सभी updates को लगातार delay किया जाए, बल्कि इस बार बहुत जल्दी public हो गई कुछ खास vulnerabilities के fixes और patches deploy होने तक one-time एक हफ़्ता रुकने का सुझाव है। बाकी बातों से मैं सहमत हूँ
    • शायद आपने लेख को ग़लत समझा। सुझाव यह नहीं है कि software release होने के बाद एक हफ़्ता रुककर install करो। मतलब यह है कि अभी से अगले 7 दिनों तक बस कुछ install ही मत करो
      क्योंकि इन vulnerabilities के patches शायद अभी उपलब्ध नहीं हैं, और अगर हैं भी तो संभव है कि जल्द ही इससे भी डरावनी vulnerabilities मिल जाएँ
    • तो फिर एक महीना या दो महीने इंतज़ार कर लो। Waiting period का मकसद पहले से install किए गए exploits के execution को रोकना नहीं, बल्कि नए exploits की installation से बचना है
    • लोकप्रिय packages की exposure ज़्यादा होती है। Artifact public हो जाए तो पूरी दुनिया उसे देख सकती है, और यह उम्मीद की जा सकती है कि कोई versions के बीच diff भी देखेगा
      लेकिन अगर कोई delay ही न हो, तो आप ऐसे exploit का शिकार हो सकते हैं जिसे अभी तक किसी ने देखा ही नहीं है
    • “पिछले कुछ महीनों” में मुझे जितने dependency compromises याद हैं, वे घंटों में नहीं बल्कि मिनटों में पकड़े गए थे। litellm, axios, bitwarden CLI, Checkmarx Docker image, Pytorch lightning, intercom/intercom-php — सबके साथ यही हुआ
      और इन compromises का पता चलना इस पर बिल्कुल निर्भर नहीं था कि उनका वास्तव में दुरुपयोग हुआ था या नहीं। इसलिए “अगर सब लोग एक हफ़्ता रुकेंगे तो attacker दो हफ़्ते रुकेंगे” वाली बात समझ नहीं आती

  • दूसरा विकल्प यह है कि आप FreeBSD जैसे operating system पर चले जाएँ, जो security को YOLO अंदाज़ में नहीं लेता
    Security fixes बिना coordination के FreeBSD kernel में यूँ ही नहीं फेंक दिए जाते। वे FreeBSD security team से होकर जाते हैं, और patch src tree में जाने के कुछ ही मिनटों के भीतर FreeBSD Update और 15.0-RELEASE के pkgbase के ज़रिए binary updates जारी हो जाते हैं
    मोटे तौर पर Slack पर “patch push कर दिया” संदेश आने में कुछ सेकंड, patch upload में 10–30 सेकंड, और mirrors sync होने में अधिकतम लगभग 1 मिनट लगता है

    • इस बारे में मैं थोड़ा skeptical हूँ। कुछ साल पहले मैंने FreeBSD security team को एक vulnerability report की थी, और कुछ हफ़्तों बाद follow-up mail भी भेजी, लेकिन कोई जवाब नहीं मिला
      निष्पक्ष रूप से कहूँ तो मेरी report किसी core component के बारे में नहीं थी और उसका exploit करना भी आसान नहीं था, लेकिन Debian, OpenBSD, SUSE, Gentoo — इन सबने एक हफ़्ते के भीतर patch कर दिया था https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
      इसका मतलब यह नहीं कि किसी एक छोटे report-handling अनुभव से पूरे operating system का आकलन कर लिया जाए। क्योंकि बाकी हर चीज़ जो मैंने देखी है, उससे तो यही लगता है कि FreeBSD security reports को काफ़ी गंभीरता से लेता है। बस यही तर्क Linux kernel bugs पर भी लागू किया जा सकता है। इस तरह patches का ख़राब management Linux में भी काफ़ी दुर्लभ है
    • अगर security की वजह से BSD पर जाना है, तो FreeBSD ही क्यों? क्या OpenBSD ज़्यादा सुरक्षित वाला विकल्प नहीं है? इन projects को देखे हुए काफ़ी समय हो गया, इसलिए पूछ रहा हूँ
    • FreeBSD security के मामले में, खासकर defaults और settings को लेकर, काफ़ी ढीला है
      यह security से ज़्यादा usability को प्राथमिकता देता है। इसका एक प्रसिद्ध उदाहरण यहाँ है: https://vez.mrsk.me/freebsd-defaults
      मैं project में योगदान देने वालों की सराहना करता हूँ, लेकिन जब तक ऐसे ख़राब defaults बने हुए हैं, मैं ईमानदारी से लोगों को वहाँ migrate करने की सलाह नहीं दे सकता
    • FreeBSD में 2019 तक user-space ASLR भी नहीं था, और दूसरी mitigations में से एक kASLR अब भी नहीं है। जो लोग security को गंभीरता से लेते हैं, उनके लिए यह कोई serious operating system नहीं है
      अगर आपको FreeBSD और security दोनों चाहिएँ, तो Shawn Webb का HardenedBSD इस्तेमाल करना ज़्यादा सही होगा
    • ऐसी बातों में हमेशा कोई न कोई आ ही जाता है। अच्छा है कि आपका पसंदीदा distro निश्चित रूप से ज़्यादा सुरक्षित है। भले ही exploits एक-अंकीय गुणक से कम हो जाएँ, आख़िर में कुछ हज़ार तो फिर भी बचेंगे ही। Ozymandias शायद Gentoo इस्तेमाल करता

  • अब security experts को भी यह मान लेना चाहिए कि हमारी दुनिया एक बेहद fragile equilibrium पर टिकी हुई है। मुझे लगता है लोग इसे सचमुच बहुत कम आँकते हैं
    सिर्फ IT की दुनिया नहीं, पूरी दुनिया असंख्य बहुत नाज़ुक संतुलनों पर बनी है। Security exploits हमेशा रहेंगे। सिर्फ software में नहीं, वास्तविक दुनिया में भी। किसी ने security conference में चुपके से प्रवेश भी कर लिया था, और वह बस एक YouTuber था। ठीक है, वह कोई ultra-secure event नहीं था, लेकिन उदाहरण के तौर पर वही याद आया। मूल बात यह है कि ज़्यादातर मामलों में security को bypass करना वास्तव में बहुत आसान होता है
    मेरा कहना यह है कि बुनियादी तौर पर हमारी दुनिया इसलिए चलती है क्योंकि कम से कम ज़्यादातर लोग इन चीज़ों का दुरुपयोग नहीं करते। मानव समाज हमेशा से ऐसे ही चलता आया है, और आगे भी शायद ऐसा ही चलेगा

    • मुझे याद है कि UK influencers के बीच “सीढ़ी और fluorescent vest” वाला एक ट्रेंड था, जिसमें वे जगहों में घुसकर दिखाते थे कि physical security कितनी लचर है https://www.youtube.com/watch?v=LTI0SeyhAPA
      जहाँ तक मुझे पता है, Max Fosh नाम के YouTuber ने International Security Expo में कई बार प्रवेश किया था। UK में https://www.youtube.com/watch?v=qM3imMiERdU और US में https://www.youtube.com/watch?v=NmgLwxK8TvA उसने क्रमशः “Rob Banks” और “Nick Everything” जैसे aliases इस्तेमाल किए
      मैंने security culture पर थोड़ा अध्ययन किया है, और ज़्यादातर बातें अंततः एक sliding scale पर आकर टिकती हैं — एक तरफ security, दूसरी तरफ convenience/accessibility। जितना ज़्यादा secure, उतना कम accessible, और इसका उल्टा भी सही है

  • npm, PyPI, Cargo जैसे dependency managers पर होने वाले supply chain attacks के लिए पहले से ही एक ठीक-ठाक समाधान मौजूद है। Configuration ऐसी हो कि सिर्फ वही package versions install हों जो कुछ दिनों से पुराने हों
    हाल के सभी बड़े attacks एक दिन के भीतर पकड़े गए और rollback कर दिए गए, इसलिए अगर ऐसा किया गया होता तो उन्हें सुरक्षित रूप से टाला जा सकता था। यह behavior default होना चाहिए। अपने-आप चुने गए beta testers और security scanner कंपनियों को latest package versions एक दिन पहले इस्तेमाल करने दो। तरीका यहाँ है: https://cooldowns.dev/

    • 3 महीने पहले Show HN पर आया यह tool शायद ज़्यादा उपयुक्त लगता है: https://github.com/artifact-keeper
      यह एक artifact manager है। यह सुनिश्चित करता है कि आप सिर्फ approved चीज़ें ही fetch करें। ज़रूरत पड़ने पर जल्दी update भी कर सकते हैं, और ज़रूरत पड़ने पर लगातार verify किए गए stable versions भी इस्तेमाल कर सकते हैं। थोड़ा configuration override करना पड़ता है, लेकिन यह आसान काम है
      मैंने कभी इसी उद्देश्य के लिए अपना एक ढीला-ढाला tool बनाया था, और यह project अच्छा लगता है
    • इससे भी बेहतर तरीका है कि कंपनी सिर्फ अपने verified repositories इस्तेमाल करे, और किसी को भी सीधे internet repositories से install करने की अनुमति न हो
      बेशक, कंपनियों के बाहर यह स्वाभाविक रूप से ज़्यादा काम नहीं करता
    • लेकिन क्या इससे security updates भी देर से नहीं मिलेंगी? बहुत-सी vulnerabilities discovery और patching से पहले वर्षों तक production में मौजूद रहती हैं
      एक बार पता चल जाने पर तुरंत exploit explosion शुरू हो जाता है, और delayed updates उत्साहित attackers को और समय देते हैं
    • व्यक्तिगत रूप से मुझे सबसे टिकाऊ तरीका Linux distributions/BSD ports/Homebrew मॉडल लगता है। यानी नई libraries को सीधे public registry में push करने के बजाय, हर नए बदलाव के लिए review होने वाली packaging scripts लिखी जाएँ
      एक और मॉडल Perl का CPAN है, जो केवल source files distribute करता है

  • जिन लोगों ने relatively हाल ही में continuous integration और containerized builds अपनाए हैं, उन्हें यह देख लेना चाहिए कि कहीं उनकी system हर build पर कई packages से latest तो नहीं खींच रही
    हम एक base container बनाकर रखते हैं जिसमें सभी external dependencies शामिल होती हैं, और उसे केवल तब explicitly refresh करते हैं जब हमें लगता है कि update का समय आ गया है
    इससे हम cutting edge से थोड़ा पीछे ज़रूर रह जाते हैं, लेकिन किसी random supply chain vulnerability के तुरंत दुनिया भर में deploy हो जाने का जोखिम बहुत कम उठाते हैं

    • ऐसा करने से आपको CI build time और flaky failures में भी बड़ी कमी दिखेगी
    • इसके अलावा, सिर्फ internal repositories का इस्तेमाल करना अच्छा है

  • यह एक सक्रिय रूप से हानिकारक opinion piece है। इसकी logic समझना मुश्किल है
    copyfail और dirtyfrag vulnerabilities वास्तव में कितनी पुरानी हैं, यह जाँचने में 45 सेकंड काफ़ी हैं। लेख पढ़ने में इससे ज़्यादा समय लगता है। Dirtyfrag ऐसे systems से भी संबंधित हो सकता है जो 2017 तक पीछे जाते हैं
    प्रभावित होने वाली चीज़ “नई” software नहीं है। और वास्तव में पुराना software तो और भी बदतर स्थिति में है, क्योंकि उसमें समस्याएँ ढूँढने के लिए कहीं ज़्यादा समय मिला है

    • मूल लेख का कहना यह है कि अगर अभी supply chain attack हुआ तो वह बहुत बुरा हो सकता है, इसलिए NPM package install/update मत करो ताकि उस जोखिम को कम किया जा सके

  • कभी न कभी कोई व्यक्ति operating system से लेकर application तक पूरे stack को proof-carrying code upgrades के साथ फिर से बनाएगा
    Trusted code चलाने का एकमात्र तरीका है proof और code का साथ में design और साथ में build होना

  • यह सिर्फ software पर लागू नहीं होता, बल्कि लगभग हर चीज़ पर लागू होता है
    याद नहीं कहाँ पढ़ा था, लेकिन अंत में बात ज़रूरत और चाहत के फ़र्क पर आकर टिकती है
    नई car खरीदनी है या used car, premium vacuum cleaner लेना है या basic, यह तय करते समय मैं इस नियम का इस्तेमाल करता हूँ। किसी चमकदार नए gadget को अपनाने, tech stack में कुछ नया जोड़ने, या नया tech stack चुनने पर भी यही बात लागू होती है

  • मैं समझना चाहता हूँ कि copyfail क्या है और इसका NPM packages से क्या संबंध है
    मैंने जो समझा, उसके मुताबिक copyfail एक kernel bug है जो malicious npm package को Linux server पर root privileges दिला सकता है
    यानी अभी जब unpatched servers मौजूद हैं, attackers के लिए NPM packages को निशाना बनाने का यह बिल्कुल सही समय है
    क्या सलाह सिर्फ “kernel update कर लो” नहीं है क्योंकि संबंधित नई समस्याएँ अब भी लगातार मिल रही हैं?

    • नवीनतम vulnerabilities के patches अभी आए ही नहीं हैं। इसलिए अगर अभी कोई नया supply chain attack होता है, तो लगभग हर system पर root मिल जाना संभव होगा, और यही इसे बेहद बुरा समय बनाता है
    • NPM supply chain attacks सचमुच बहुत तेज़ी से फैलते हैं
      अगर कोई लोकप्रिय NPM package compromise होकर उसमें copy.fail exploit शामिल हो, तो बहुत-सी systems root privilege escalation के प्रति vulnerable हो जाएँगी
    • सलाह “kernel update कर लो” नहीं है क्योंकि update उपलब्ध ही नहीं है। copy.fail के बाद मिली नवीनतम vulnerabilities का अभी तक कोई fix नहीं है