- 19 जुलाई 2024 को दुनिया भर में हुई Windows गड़बड़ी एक ऐसा मामला था जिसमें सुरक्षा उत्पाद के kernel driver update ने गलत memory read करा दिया, जिससे blue screen और boot loop हुए
- eBPF kernel के अंदर चलता है, लेकिन verifier और sandbox के जरिए खतरनाक code को reject करता है, ताकि कोई एक program पूरे system को crash न कर सके
- Linux में eBPF पहले से मौजूद है, और Microsoft का eBPF for Windows production-ready होने पर Windows security software को भी इसी तरीके पर shift किया जा सकेगा
- Google, Meta, Cisco जैसी बड़ी tech कंपनियां और eBPF-आधारित security startups इसकी speed, गहरी visibility और safety guarantees का इस्तेमाल करके security products और detection systems को scale कर रहे हैं
- kernel driver या kernel module वाले commercial software खरीदने वाली कंपनियां Linux में अभी, और Windows में जल्द ही eBPF support को vendor requirement बना सकती हैं
19 जुलाई की Windows गड़बड़ी ने kernel code के जोखिम दिखाए
- 19 जुलाई 2024 की गड़बड़ी kernel programming के अंतर्निहित जोखिमों को दिखाने वाला अभूतपूर्व उदाहरण थी
- दुनिया भर के Windows computers में blue screen of death और boot loop आए, और अस्पतालों, airlines, banks, grocery stores और broadcasters में व्यवधान हुआ
- कारण एक व्यापक रूप से इस्तेमाल होने वाले security product का config update था, जिसमें Windows systems के लिए kernel driver शामिल था
- update के बाद kernel driver ने गलत memory पढ़ने की कोशिश की, और इस तरह की error kernel को crash कर सकती है
eBPF जिन crashes को रोक सकता है
- eBPF अब कोई acronym नहीं है; यह web browser में embedded safe JavaScript runtime जैसा safe kernel execution environment है
- Linux users के systems में eBPF पहले से होने की संभावना अधिक है, और eBPF कुछ साल पहले Linux kernel में शामिल हो चुका है
- eBPF programs को इस तरह सीमित किया जाता है कि वे पूरे system को crash न कर सकें
- software verifier safety की जांच करता है
- program वास्तव में sandbox के अंदर चलता है
- अगर verifier असुरक्षित code पाता है, तो program reject हो जाता है और run नहीं होता
- Linux implementation का verifier 20,000 से अधिक lines of code से बना है, जिसमें Meta, Isovalent, Google जैसी industry और Rutgers University, University of Washington जैसी academia का योगदान है
- मजबूत security, कम resource usage और crash prevention eBPF के मुख्य फायदे हैं
Linux और Windows में लागू करने की संभावना
- इस गड़बड़ी का कारण बनी security company Linux systems पर पहले से eBPF अपनाने की प्रक्रिया में थी
- Microsoft का eBPF support for Windows production-ready हो जाने पर Windows security software को भी eBPF पर port किया जा सकता है
- eBPF पर shift किए गए Windows security agents ऐसे रूप में होंगे कि वे Windows kernel crash नहीं करा सकेंगे
security industry और बड़ी tech कंपनियों में adoption
- eBPF-आधारित security startups Oligo और Uptycs ने हालिया गड़बड़ी के बाद eBPF पर जाने के फायदे बताए हैं
- बड़ी tech कंपनियां भी security use cases के लिए eBPF अपना रही हैं
- Cisco ने eBPF startup Isovalent को acquire किया और security enforcement व monitoring के लिए fabric Cisco Hypershield की घोषणा की
- Google और Meta eBPF की speed, गहरी visibility और safety guarantees के आधार पर बड़े पैमाने के environments में malicious behavior detect और block करते हैं
- eBPF security के अलावा networking और observability में भी इस्तेमाल होता है
eBPF की सीमाएं और operations में पूरक उपाय
- eBPF program सबसे बुरा जो कर सकता है, वह CPU cycles या memory जैसे resources को अवांछनीय स्तर तक ज्यादा consume करना है
- यह wasteful code तक को नहीं रोकता, लेकिन system crash तक पहुंचने वाली गंभीर समस्याओं को block करता है
- eBPF भी नई technology है, इसलिए management code में bugs रहे हैं, और हालिया खबरों में आई उसी security company द्वारा खोजा गया Linux kernel panic का मामला भी है
- ऐसे bugs को eBPF में fix करने पर fix सभी eBPF vendors पर लागू होता है, जिससे overall security तेजी से बेहतर हो सकती है
- deployment risk eBPF से ही खत्म नहीं होता; साथ में इस्तेमाल की जा सकने वाली operational techniques बची रहती हैं
- canary testing
- phased rollout
- सामान्य resilience engineering
खरीदार जो बदलाव मांग सकते हैं
- eBPF approach की अहम बात यह है कि यह Linux और Windows kernel दोनों में built-in होने वाला software solution है, और इस use case में पहले से अपनाया जा चुका है
- अगर कंपनियां kernel driver या kernel module वाले commercial software के लिए भुगतान करती हैं, तो वे eBPF को requirement बना सकती हैं
- Linux में यह आज संभव है, और Windows में जल्द संभव हो जाएगा
- कुछ vendors ने पहले ही proactive रूप से eBPF अपना लिया है, लेकिन दूसरे vendors के लिए भुगतान करने वाले customers की मांग जरूरी हो सकती है
1 टिप्पणियां
Hacker News की राय
Windows के लिए eBPF जो “hooks” देता है, उनकी सूची देखकर यह हक़ीक़त से काफ़ी दूर लगती है। अभी तो यह आने वाले packets और socket operations तक ही सीमित है, इसलिए लगता है कि Microsoft Berkeley Packet Filter को शाब्दिक अर्थ में सिर्फ़ packet filtering के लिए इस्तेमाल करने की उम्मीद कर रहा है
यह I/O filtering, object creation/usage, या CrowdStrike जैसे drivers द्वारा NT kernel में लगाए गए असंख्य points जैसी चीज़ों से अलग है
और kernel space में चल रहे दूसरे third-party कचरे की निगरानी करनी हो, तो anti-malware को भी kernel के अंदर होना पड़ेगा। ELAM(early-launch anti-malware) anti-malware drivers को पहले load करता है ताकि वे दूसरे drivers के व्यवहार की निगरानी कर सकें, लेकिन eBPF से ऐसा संभव होगा या नहीं, इस पर बहुत संदेह है
Microsoft को eBPF से kernel-space anti-malware drivers को बदलना हो तो अभी बहुत लंबा रास्ता तय करना है
https://microsoft.github.io/ebpf-for-windows/ebpf__structs_8...
तुलना करें तो लोग Google Chrome में JavaScript websites के ज़रिए banking करते हैं, लेकिन Microsoft Edge में कहा जाए, “JavaScript supported नहीं है, यह .EXE download करके चलाइए।” बात यह कम है कि Microsoft JavaScript या eBPF को support करेगा “या नहीं”, और ज़्यादा यह कि “कब” करेगा
Brendan Gregg जैसे लोगों से बहस करने की मेरी इच्छा नहीं है, लेकिन मैं चाहता हूँ कि इस क्षेत्र के vendors पूरे failure chain की ज़्यादा समग्र जाँच करें। outage होने के 3 दिन बाद जब “x, y तारीख़ को हुई समस्या को हल कर देगा” जैसी बात आती है, तो थोड़ा सतर्क होना पड़ता है
यह सही भी हो सकता है, लेकिन analysis किए बिना blind spots रह सकते हैं, और review के बाद ठीक से खारिज कर देने लायक बहुत से alternatives भी हो सकते हैं
खासकर “सबसे बुरा नकारात्मक परिणाम सिर्फ़ CPU waste है” — इस हिस्से से सहमत होना मुश्किल है। कुछ bug classes में यह सही हो सकता है, लेकिन ऐसे failure modes काफ़ी हैं जहाँ गलत ruleset system को बुरी तरह brick कर सकता है और recovery को मुश्किल बना सकता है
इसका मतलब यह नहीं कि eBPF-आधारित security modules बहुत से vendors के लिए सही विकल्प नहीं हो सकते, बल्कि यह कि हमें समझना चाहिए कि वे कौन से risks से बचाते हैं, किनसे नहीं बचाते, और failure chain के किस हिस्से को address करते हैं
https://opensource.microsoft.com/blog/2021/05/10/making-ebpf...
https://lwn.net/Articles/857215/
अगर सच में चिंता है, तो अपनी राय देने के लिए discussion channels भी हैं, और वे GitHub पर दर्ज हैं
https://github.com/microsoft/ebpf-for-windows
हो सकता है कि उसका जवाब पहले से मौजूद हो, और अगर नहीं है, तो वहीं उस पर बात की जा सकती है
यह सही नहीं है। अगर सिस्टम के चलने की संरचना ऐसी है कि कोई code fragment होना ही चाहिए, तो वह code टूटने पर सिस्टम को बिल्कुल चलना ही नहीं चाहिए। failure को ignore करना अजीब है
उदाहरण के लिए, अगर किसी medical device का driver code लोगों को जला न दे, इसके लिए safety interlock की गारंटी देता है, तो safety बंद रहते हुए सामान्य रूप से चलने देने से बेहतर मैं पूरे सिस्टम को रुकने देना चुनूंगा
आखिर नीचे जाएँ तो भी वही समस्या बनी रहती है
Linux वास्तव में क्या करता है, यह मुझे नहीं पता, लेकिन ऐसी दुनिया की कल्पना की जा सकती है जहाँ गलत input पर behavior configurable हो
और वह बात हमेशा सही भी नहीं है। सामान्य मामलों में मैं सहमत हूँ, लेकिन कुछ context में चलते रहना ज़रूरी होता है। जो उदाहरण तुरंत याद आता है वह automated Mars lander का guidance computer है। पृथ्वी के साथ round-trip latency इतनी ज़्यादा होती है कि ज़िम्मेदारी टाली नहीं जा सकती
shutdown करने पर crash होगा, लेकिन damage की स्थिति में best effort करने पर शायद सिर्फ crash ही होगा, इसलिए वह विकल्प बेहतर हो सकता है
पूरा operating system ही brick हो जाए तो यह कहीं बड़ा problem बन जाता है, क्योंकि फिर IT technician को सीधे आकर ठीक करना पड़ता है। ऐसा न होता तो सिर्फ defective driver को update करना काफी होता
कार भी wiper fluid न होने पर start होने से मना नहीं करती
शुक्रवार को प्रभावित हुई ज़्यादातर organizations शायद 24 घंटे के लिए malware attack या unauthorized use के थोड़ा बढ़े जोखिम को उस वास्तविक total IT collapse से बेहतर मानतीं, जिसका उन्होंने सामना किया
और यह भी ज़रूरी नहीं था कि उस bug से अनिवार्य रूप से blue screen ही आए। सिस्टम undefined state और unbounded परिणामों के साथ चलता भी रह सकता था
eBPF हो तो कम से कम कुछ संभावित errors detect किए जा सकते हैं और उसके आधार पर risk management decision लिया जा सकता है
update करने के लिए caller को कोई अलग function call करना पड़ता है, इसलिए ज़िम्मेदारी kernel को side-channel से छेड़ सकने वाले व्यक्ति पर नहीं, बल्कि caller पर रहती है
अगर दिखाए गए hash के अनुरूप function मौजूद नहीं है, तो उसे call नहीं किया जा सकता, और मौजूद होने पर भी intended तरीके के अलावा call नहीं किया जा सकता, इसलिए वांछित “पूरी तरह काम करे या बिल्कुल न करे” वाला गुण मिल जाता है
और गलत state पर प्रतिक्रिया ज़रूरी नहीं कि सिर्फ “ignore” ही हो। restricted user login को disable किया जा सकता है या screen बंद की जा सकती है
अगर चिंता यह है कि malware इसका दुरुपयोग कर सकता है, तो जब malware पहले से antivirus की disk files को modify कर सकता हो, तब यह मानना कि सिस्टम खुद उसे सही तरह से handle कर लेगा, मुझे अच्छा विचार नहीं लगता
security के ऊपरी ढाँचे को report करना, और बाहरी system से network access disable या restrict करवाना ज़्यादा सुरक्षित हो सकता है। आगे बढ़कर देखें तो ऐसे उपायों के लिए system में दखल देने का अधिकार नहीं, सिर्फ observation का अधिकार भी काफी हो सकता है, इसलिए antivirus system खुद malware path या ऐसे bugs का कारण बनने की संभावना भी कम हो जाती है
eBPF शानदार है और कई उद्देश्यों के लिए इस्तेमाल होकर बहुत कुछ बेहतर कर सकता है, लेकिन “खराब software update की वजह से computer crash नहीं होगा” कहना अतिशयोक्ति लगता है
मान लें कि BPF में खुद bug नहीं है, तब भी kernel hooks का दायरा काफ़ी बड़ा है, वे hooks eBPF code को call करते हैं, और वह code फिर kernel को call कर सकता है
https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
खासकर bpf_probe_read_kernel() बहुत इस्तेमाल होता है, लेकिन सुरक्षित नहीं है। OOPS या crash से बचने की काफ़ी कोशिश की जाती है, लेकिन यह कभी पूरी तरह perfect नहीं होता
बाकी list में भी ऐसी कई चीज़ें हैं जो actual oops या panic न भी करें, तब भी सिस्टम को आसानी से बिगाड़ सकती हैं
और अगर यह user space की “malicious activity” को detect करके रोकने वाला tool है, तो यह हर चीज़ को malicious मानना शुरू करके computer को बेकार भी बना सकता है
दूसरी ओर, eBPF में user space की तरफ़ कोई वास्तविक security model नहीं है। eBPF program का actual attach, जिस kernel object से वह जुड़ता है उस पर किसी sensible permission operation से नहीं, बल्कि bpf() system call के ज़रिए होता है, और container द्वारा इस्तेमाल किए गए eBPF को उसी container के भीतर सीमित रखने की कोई व्यवस्था भी नहीं है। bpf_probe_read_kernel() मूल रूप से पूरी kernel memory पढ़ सकता है
इसलिए सामान्य kernel C code की तुलना में eBPF की बढ़त कुछ वैसी है जैसे limited unsafe API surface वाली safe language में code लिखना। इस तरह के काम में यह बड़ा improvement है, लेकिन बिल्कुल perfect नहीं
यह भी कहा जाता है कि verifier सख्त है और Linux implementation 20,000 lines से ज़्यादा है, लेकिन verifier बेहिसाब जटिल है। मैं हाथ से लिखी 20,000-line logic की बजाय formal methods पर आधारित नींव देखना चाहूँगा
“eBPF प्रोग्राम software verifier से safety check पास करते हैं और व्यवहार में sandbox के भीतर चलते हैं, इसलिए पूरे सिस्टम को crash नहीं कर सकते” — इस बात पर संदेह होता है
क्या operating system का एक उद्देश्य software की निगरानी करना नहीं है? समझता हूँ कि यह operating system खुद से जुड़ी समस्या है, लेकिन अगर हम निगरानी करने वाले की निगरानी के लिए एक और layer जोड़ें, तो क्या अंततः उस layer की भी फिर निगरानी नहीं करनी होगी?
क्या यह बेहतर नहीं होगा कि भोलेपन से यह मानने के बजाय कि नई complexity लंबी अवधि में बेहतर होगी, हम complexity reduction को चुनें?
पुराना तरीका kernel driver लोड करने, बहुत सारे system calls पर hook लगाने, और फिर उम्मीद करने का था कि कुछ खराब न हो. गलती होने पर panic आ सकता है, लेकिन Linux काफ़ी मज़बूत है
eBPF तरीका इस बात के ज़्यादा क़रीब है कि आप अपनी चाही हुई जानकारी eBPF-विशेष instructions के ज़रिए माँगें
यह कैसे काम करता है, उसका सार यहाँ है: https://ebpf.io/what-is-ebpf/
तकनीक सुनने में शानदार लगती है, लेकिन असल में जो बात बहुत गंभीर थी वह यह थी कि “canary testing, staged rollout, resilience engineering जैसी software deployment risk mitigation विधियाँ भी इस्तेमाल की जा सकती हैं”
बुनियादी industry-standard quality control लागू करने के लिए किसी नई तकनीक की ज़रूरत नहीं होती
इस घटना की याद में शायद अब शुक्रवार को छुट्टी शुरू कर देनी चाहिए. अगर लोगों पर काम का दबाव कम होता, और उनके पास रुककर यह सोचने का समय होता कि चीज़ें किस दिशा में जा रही हैं और वे उस प्रवाह को कैसे प्रभावित कर सकते हैं, तो संभव है नुकसान कम होता
Linux implementation का verifier 20,000 lines से ज़्यादा का है और उसमें industry व academia दोनों ने योगदान दिया है — यह सुनकर उल्टा आश्वस्ति नहीं मिलती. अतिरिक्त attack surface भी एक समस्या है, लेकिन इतने बड़े codebase की गारंटी आख़िर कौन दे सकता है?
WebAssembly verifier काफ़ी अधिक सरल होने का आभास देता है
अगर filter boot के समय लोड हो और हर चीज़ पर hook लगा दे, तो एक ही bug सिस्टम को इस हद तक lock कर सकता है कि न उसे चलाया जा सके न patch किया जा सके. उदाहरण के लिए, अगर एक खाली allowlist लोड हो जाए, तो boot loop बस service denial के एक और रूप में बदल सकता है
अगर Microsoft recovery के लिए ज़रूरी core elements को hardcoded allowlist में डाल दे, तो ऐसे tool के bug को ठीक करना आसान हो सकता है, लेकिन fix deploy होने तक सिस्टम चालू होते हुए भी अनुपयोगी रह सकता है — यानी व्यवहारिक रूप से downtime बना रहेगा
blog post में लिखा है कि “eBPF ऐसे crashes के प्रति immune है”
मैंने खोजा, लेकिन कोई ठोस बात नहीं मिली, और अब भी लगता है कि यह कुछ न कुछ बिगाड़ सकता है. अच्छा होगा अगर कोई eBPF expert इस दावे को समझाए. मुझे जो सबसे अच्छा संदर्भ मिला, वह यह है: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...