CrowdStrike CSAgent.sys क्रैश के कारण की शुरुआती विस्तृत जानकारी

 (twitter.com/patrickwardle)
1 पॉइंट द्वारा GN⁺ 2024-07-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर में हुए Windows क्रैश का शुरुआती विश्लेषण यह बताता है कि CrowdStrike CSAgent.sys ने गलत memory address को refer करने वाला flow चलाया
  • समस्या वाला command mov r9d, [r8] था, और R8 में pointer array से index के जरिए निकाला गया unmapped address था
  • C-00000291-...xxx.sys फ़ाइलें kernel driver नहीं बल्कि CSAgent.sys द्वारा पढ़ा जाने वाला obfuscated data लग रही थीं, और CrowdStrike ने पुष्टि की कि ये Channel Files configuration files हैं
  • CrowdStrike ने कहा कि C-00000291- ने logic error पैदा की, जिससे OS crash हुआ, और Channel File के अंदर null byte को कारण मानने से इनकार किया
  • इस deployment को version update नहीं बल्कि content update के रूप में जारी किया गया, इसलिए कुछ clients के staging control bypass हो गए, और crash report कारण विश्लेषण का मुख्य सुराग बना

CSAgent.sys क्रैश flow

  • शुरुआती विश्लेषण CrowdStrike के CSAgent.sys की reverse engineering और एक single crash dump पर आधारित static analysis था
    • Windows system या VM के बिना material साझा किया गया था और आगे की जांच के लिए कहा गया था
    • CSAgent.sys का विश्लेषण VirusTotal पर अपलोड की गई फ़ाइल के आधार पर किया गया: VirusTotal sample
  • क्रैश point mov r9d, [r8] command था
    • R8 एक unmapped address था
    • यह value RAX में मौजूद pointer array से RDX index (0x14 * 0x8) के जरिए लाई गई address थी
  • C-00000291-...32.sys जैसी दूसरी .sys फ़ाइलें असली drivers नहीं बल्कि obfuscated data जैसी दिख रही थीं
    • ऐसे संकेत थे कि CSAgent.sys इन फ़ाइलों को refer या read कर रहा था
    • फ़ाइलें delete करने पर crash रुक जाने की वजह से यह संभावना उठी कि फ़ाइल contents ने CSAgent.sys crash को प्रभावित किया
    • यह भी जोड़ा गया कि debugging करने पर इसे और आसानी से verify किया जा सकता है
  • साझा की गई .zip में कई CSAgent.sys versions, IDB, और कई C-....sys फ़ाइलें शामिल थीं
    • बताया गया कि नई फ़ाइलों में से एक में शायद “fix” शामिल था
    • साझा लिंक: Google Drive zip

Channel Files और CrowdStrike की पुष्टि

  • Kevin Beaumont ने लिखा कि समस्या पैदा करने वाली .sys फ़ाइलें channel update files थीं, और गलत format ने ऊपरी CS driver को crash कर दिया
  • CrowdStrike की technical explanation ने शुरुआती analysis जैसी ही दिशा की पुष्टि की
    • C-...sys फ़ाइलें kernel drivers नहीं बल्कि Channel Files नाम की configuration files हैं
    • C-00000291- ने logic error trigger की, और उसके परिणामस्वरूप CSAgent.sys के जरिए OS crash हुआ
    • लिंक: CrowdStrike technical explanation
  • कुछ लोगों ने खाली 0x0 Channel File को कारण माना, लेकिन CrowdStrike ने इससे इनकार किया कि समस्या Channel File के अंदर के null byte से जुड़ी थी
    • Malware Utkonos ने उस check की ओर इशारा किया जिसमें फ़ाइल का 0xaaaaaaaa से शुरू होना जरूरी बताया गया: संबंधित पोस्ट
  • पुष्टि हुई कि channel update कुछ clients के staging control को bypass करके वितरित हुआ
    • कुछ IT admins ने CrowdStrike policy में latest version को ignore करने की setting की थी, लेकिन यह update version update नहीं बल्कि content update था, इसलिए bypass हो गया
    • संबंधित पोस्ट: ResetEra थ्रेड
  • CrowdStrike patents में भी channel files शब्द कई बार आता है
    • उदाहरण के तौर पर US11822515B2 और US11645397B2 का उल्लेख किया गया
    • search query है channel file assignee:(Crowdstrike, Inc.)

crash report और macOS System Extensions से जुड़े सुराग

  • crash report CrowdStrike crash को समझने का एक तरीका था, और इसका उपयोग macOS के दूसरे 0day को उजागर करने में भी हुआ था
    • संबंधित Black Hat talk का शीर्षक है “The Hidden Treasure of Crash Reports?”
    • लिंक: Black Hat presentation page
  • Apple द्वारा 3rd-party kext को हटाकर user-mode System Extensions की ओर जाना सकारात्मक माना गया
    • हालांकि यह भी लिखा गया कि इस transition के दौरान kernel panic, privilege escalation, और security tool unload जैसी समस्याएँ थीं
  • macOS में user-mode System Extensions को support करने वाले kernel code में कई bugs थे, और ऐसे मामले भी थे जहाँ user mode में ले जाए गए security tools ने Apple के core kext में बड़े पैमाने पर kernel panic कर दिए
  • core macOS System Extension framework में privilege escalation issue के रूप में CVE-2019-8805 का उल्लेख किया गया
  • System Extensions handling flaw की वजह से unprivileged code या malware security tools को unload करा सकता है
    • उदाहरण के तौर पर कहा गया कि नवीनतम macOS में भी trusted System Extension के रूप में चलने वाले firewall LuLu को terminate किया जा सकता है
    • यह bug केवल LuLu तक सीमित नहीं है

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

1 टिप्पणियां

 
GN⁺ 2024-07-22
Hacker News की रायें

  • “यह एक content update है जो BSOD पैदा करता है, और हटाने पर ठीक हो जाता है” यह सुनते ही लगा कि यह टूटा हुआ binary data और खराब लिखे parser का combo है—इस पर £100 लगा सकता था
    पिछले करीब 10 सालों से computing को काफ़ी गंभीरता से कर रहा हूँ, cybersecurity बिल्कुल नहीं की, लेकिन मुझे लगता है कि लगभग हर CVE, crash, bug, performance गिरावट और दर्द binary data को वापस machine-readable data structures में deserialize करने की प्रक्रिया से ही निकलता है
    वजह यह है कि human programmers edge cases छोड़ देते हैं और imperative languages उन्हें ऐसा करने देती हैं। इसमें decompression algorithms, font outline readers, image/video/audio parsers, game data parsers, XML/HTML parsers, OpenSSL के certificate/signature/key parsers, और अब CrowdStrike EDR का content parser—सब शामिल हैं
    दूसरी hypothesis भी जोड़कर £50 और लगा सकता हूँ

    • मुझे लगता है कि एक साथ कम से कम पाँच चीज़ें गलत हुईं। kernel module की खराब error handling ने पूरे operating system को गिरा दिया, corrupt file को बार-बार parse करके boot loop बना दिया, और file को delete या corrupt के रूप में mark भी नहीं किया
      corrupt file या तो internal testing से पास हो गई, या internal testing थी ही नहीं, और update apply होने के समय से जुड़ी individual settings भी शायद ignore हुईं। ऊपर से इसे पूरी दुनिया में एक साथ deploy किया गया, जिससे नुकसान सीमित नहीं हो पाया, और file corruption असल में हुई क्यों—यह भी अभी पता नहीं
    • 2023 की top 25 common weaknesses list यहाँ है: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
      Untrusted Data Deserialization (CWE-502) 15वें स्थान पर था, जबकि नंबर 1 Out-of-bounds Write (CWE-787) और नंबर 4 Use After Free (CWE-416) था। 2019 से हर बार list में आने वाली weaknesses यहाँ संकलित हैं: https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
    • “लगभग 100%” की बजाय मुझे यह करीब 98% लगता है। बाकी 2% logic bugs, configuration mistakes, खराब defaults, और शुरू से ही insecure design choices से भरता है
      संदर्भ के लिए, information security field में 30 साल से ज़्यादा काम किया है
    • इसे imperative programming के सिर मढ़ना मुश्किल लगता है। उदाहरण के लिए Rust imperative है, लेकिन switch में छूटे cases को काफी अच्छी तरह पकड़ लेता है
      इसके उलट 20 साल पहले मैंने जो Scheme variant इस्तेमाल किया था वह functional था, लेकिन यह check नहीं करता था कि सभी cases cover हुए हैं या नहीं; और Haskell का ghc भी कुछ साल पहले तक यह check default रूप से enable नहीं रखता था। अब बदला है या नहीं, नहीं पता
    • समझ नहीं आता कि ज़्यादा घातक क्या था: असल में error/failure handling का न होना, या यह कि “channel update ने customers के staging controls को bypass किया और सब तक deploy हो गया”
      कुछ IT admins ने confirm किया कि उन्होंने CS policy को latest version ignore करने पर set किया था, फिर भी यह bypass हो गया क्योंकि यह “version update” नहीं बल्कि “content update” था। अगर content update client को तोड़ सकता है, तो उसे staging controls या policy bypass करने की अनुमति नहीं होनी चाहिए

  • CS जैसे rootkit-based endpoint monitoring software की वाकई जरूरत है या नहीं, यह अलग बात है; लेकिन इस क्षेत्र को ज़्यादा ethical standards की ओर ले जाने के लिए open source alternatives ताकतवर हो सकते हैं
    अगर core tool open source हो, तो वह ठीक-ठीक क्या कर रहा है यह transparent होगा, और public audit कर सकेगी कि उसमें backdoor या गंभीर bugs नहीं हैं। वहीं security teams द्वारा malware signatures supply करने का तरीका अब भी business model हो सकता है

    • मुझे ऐसा नहीं लगता। Kolide ऐसी कोशिशों में से एक है, लेकिन उसकी actual practices और enterprise में उपयोग का तरीका proprietary products जितना ही संदिग्ध है
      user के नज़रिए से यह भरोसा नहीं किया जा सकता कि open source monitoring rootkit बेहतर tested/developed है या मेरे हितों का ध्यान रखता है। समस्या पूरी monitoring software category है। इसका अस्तित्व ही नहीं होना चाहिए। जो कंपनियाँ ऐसी चीज़ें इस्तेमाल करती हैं, वे security नहीं समझतीं, employees पर trust नहीं करतीं, और काम करने के लिए अच्छी जगह भी नहीं होतीं
    • open source alternative के रूप में GRR है: https://github.com/google/grr
      यह Google के सभी client devices में होता है
    • red team में EDR bypass के लिए malware develop करने वाले व्यक्ति के रूप में कह सकता हूँ कि EDR systems जरूरी हैं। “rootkit-based endpoint monitoring” वाला phrase game community की गलतफहमियों से अक्सर निकला inaccurate description है
      ऐसे tools sophisticated threats के खिलाफ जरूरी protection देते हैं और वास्तव में पकड़ते हैं। अगर test में Windows machines शामिल हों, तो EDR न होने पर मेरा काम 90% आसान हो जाता है
      OpenEDR जैसे open source EDR भी हैं, लेकिन वे पुराने हैं और telemetry quality खराब है: https://github.com/ComodoSecurity/openedr. GitHub के तरह-तरह के proof-of-concept code जोड़कर production EDR बनाना अव्यावहारिक और insecure है
      EDR sensor खुद attack target बन जाता है। attacker के नज़रिए से अक्सर EDR ही एकमात्र बाधा होता है, इसलिए इसे open source करने पर malicious code contributions से development धीमी करने या vulnerabilities plant करने का risk बढ़ जाता है। security sensor development बेहद adversarial environment है, जहाँ सामने वाला कौन है यह पक्का नहीं हो सकता
      असल में मामला लगभग उल्टा है। Elastic Security के detection rules जैसे open source malware heuristic rules मौजूद हैं: https://github.com/elastic/detection-rules. Elastic भी kernel driver सहित EDR देता है, और अनुभव के आधार पर उसे bypass करना कठिनतर है। Windows पर driver-less EDR बनाइए तो मेरा काम और आसान हो जाएगा
      EDR sensors पहले से ही security researchers और attackers द्वारा “audit” किए जा रहे हैं। कमजोरियाँ खोजने के लिए reverse engineering और debugging लगातार होती रहती है। अगर EDR में kernel mode shellcode को ज्यों का त्यों लेकर execute करने जैसे स्तर की समस्या मिले, तो जाहिर है उसे सार्वजनिक किया जाएगा
    • CrowdStrike जो value देता है वह signature database maintenance और दुनिया भर के attack campaigns monitor करने की क्षमता है। इसके लिए काफी resources चाहिए, जो open source project के पास होना मुश्किल है
      यह simple hash lookup program से कहीं ज्यादा complex है
    • security असल में कोई ऐसा product नहीं है जिसे बस खरीद लिया जाए या outsource कर दिया जाए, लेकिन reality यही बन गई है

  • यह समझना मुश्किल है कि test deployment में यह क्यों नहीं पकड़ा गया। जिज्ञासा है कि बाहरी दुनिया में deploy करने पर ही समस्या पैदा कराने वाला फर्क क्या था
    यह मानना कठिन है कि deployment से पहले test नहीं किया गया था, और कंपनियों के पास भी third-party components deploy करने से पहले test environment होना चाहिए। Development के दौरान package install करते समय failure या समस्या होना आम है, लेकिन production environment में बिना test सीधे डालना अच्छा है, ऐसा कोई नहीं सोचता। समझ नहीं आता कि इस मामले में अलग क्या था

    • मेरा अनुमान है कि code changes और data files के लिए दो अलग pipelines रहे होंगे
      Pipeline 1 में software code update को अहम change माना गया होगा और non-production environment व canary testing से गुजरकर नया “version” global deploy किया गया होगा
      Pipeline 2 में content/channel updates को अलग तरह से handle किया गया होगा। इस रास्ते से सिर्फ नई malware signatures जैसी चीजें deploy होती हैं, इसलिए माना गया होगा कि नई file standard format की data file है और “execute” नहीं होती, बस पढ़ी जाती है
      यह pipeline खुद शुरुआत में test की गई होगी और संतोषजनक ढंग से काम करती मानी गई होगी, लेकिन generated data file की integrity validate करने या उससे भी अहम, software के latest used version पर deploy करने पर यह बिना error काम करती है या नहीं, यह check करने वाला test step नहीं रहा होगा
      channel files रोज़ पढ़ने वाले agent software को Pipeline 1 में संभव सभी data file sizes और mock content के साथ “thoroughly” test किया गया होगा। गलत data file को तो जाहिर तौर पर error देकर reject करना चाहिए था
      इस बार का सटीक scenario शायद यह था कि दूसरे रास्ते की टूटी हुई pipeline ने एक अजीब तरह की invalid data file बनाई, और उस specific case की कल्पना या testing software version की development/testing/deployment pipeline में नहीं की गई थी
      अगर यह सही है तो सीख साफ है। “Data” only deployment भी हो, pipeline कितनी भी standardized और stable हो, large-scale deployment से पहले testing अनिवार्य है। Cost और delay बढ़ेंगे, लेकिन इसे स्वीकार करना होगा। यह कुछ वैसा ही है जैसे लोग “security” software के लिए पैसे देते हैं
      Enterprise customers के लिए भी यही बात लागू होती है: नए deployment artifacts को अपने IT environment के non-production area में test करना चाहिए, या पूरी production fleet में allow करने से पहले canary deployment रखना चाहिए
    • अभी मौजूद सीमित evidence को देखें तो यह बहुत कम संभव लगता है कि इस deployment की अच्छी testing हुई थी। ज्यादा plausible यह है कि किसी मनमाने SLA को पूरा करने के लिए definition updates को ढीले-ढाले तरीके से roll out किया गया और आखिरकार यह फट पड़ा
      जब कंपनी endpoint security और network anomaly detection में enter करने की कोशिश कर रही थी, तब कई potential customers ने अलग-अलग CVE types और severity levels के लिए 4-hour SLA मांगा था। यानी 24/7 on-call security engineers और 4 घंटे से कम में definition creation/deployment चाहिए था, और उन 4 घंटों का मतलब था कि targets के 100% तक deploy किया जा सके
      Zero-day के लिए 4 घंटे के अंदर high-quality definitions लिखना और deploy करना भी मुश्किल है, testing pipeline से गुजारना और भी मुश्किल, और असल में cover करने वाले नए tests लिखना तो अलग ही बात है। उस क्षेत्र में इसे “normal” माना जाता था, इसलिए हमने जल्दी ही हार मान ली। CS भी यहां इसी तरह काम कर रहा हो तो हैरानी नहीं होगी
    • संभव है कि definition updates का automated test deployment current version के definition consumer को run नहीं कर रहा था, बल्कि सिर्फ किसी पुराने unaffected version को run कर रहा था
    • मैंने ऐसी जगहें देखी हैं जहां failed release को बस “normal engineering का हिस्सा” मान लिया जाता है। जैसे कोई भी perfect नहीं होता
    • यह मानना मुश्किल है कि testing बिल्कुल नहीं हुई। संभव है virus signatures को engine के against test किया गया हो, लेकिन final release artifact यानी .sys file को check नहीं किया गया, और packaging step में bug आ गया हो
      फिर भी यह बहुत खराब है, लेकिन अगर बिना किसी test के release किया गया था तो यह सचमुच shockingly negligent होगा

  • जो बात समझ नहीं आती वह बहुत कम technical, लेकिन ज्यादा महत्वपूर्ण है। Blast radius इतना बड़ा क्यों था, यह समझ नहीं आता
    इससे कहीं कम महत्वपूर्ण services के लिए भी मैंने automatic monitoring और rollback के साथ बहुत धीमे deployment देखे हैं। पहले customer traffic के बिना beta में deploy, फिर कोई समस्या न हो तो fleet के छोटे हिस्से में deploy, और फिर updates पाने वाले hosts का ratio धीरे-धीरे बढ़ाना
    इस तरीके से समस्या तुरंत रुक जाती, और मुझे लगा था कि यही सामान्य practice है

    • यह software update नहीं बल्कि signature database update था। यह ऐसी चीज है जिसे जितनी जल्दी हो सके deploy होना चाहिए
      जब आपको किसी नए virus के बारे में पता चलता है, वह पहले ही wild में फैल चुका होता है, इसलिए हर minute मायने रखता है। आप नहीं चाहेंगे कि एक दिन delay करने के बाद पता चले कि आपका server 20 घंटे पहले compromise हो चुका था
    • Code updates के लिए canary release procedure रहा भी हो, तो configuration updates शायद अलग channel थे
      उम्मीद रही होगी कि potentially breaking changes नहीं चाहिए, लेकिन latest virus detection rules लगातार चाहिए। छूटा हुआ edge case यह था कि untested configuration existing code को तोड़ सकती है
      Source pure speculation है, इसलिए news article में quote न करें
    • इस incident के impact को देखते हुए, पहले deploy करने के लिए बड़ा Windows client staging environment होना चाहिए था
      इस समस्या से बचने या कम से कम इसके होने का risk घटाने के कई तरीके थे, लेकिन हमेशा की तरह profit लोगों से आगे रहा
    • लगता नहीं कि वे अपने ही organization में अपना software dogfood करते हैं। शायद अपनी कंपनी के अंदर भी उन्हें यह software बहुत useful नहीं लगता
    • thread में ही जवाब है। तुलना के लिए, जब मैं AV company में काम करता था, तो अगर MS द्वारा बताए गए numbers सही हैं, तो हम इससे कहीं बड़े customer base पर दिन में करीब 4 बार updates push करते थे

  • यह हैरानी की बात है कि इस घटना में Microsoft की भूमिका पर लगभग चर्चा ही नहीं हो रही। Microsoft उस bug के लिए सीधे जिम्मेदार नहीं है जिसने crash कराया, लेकिन उसने ऐसा माहौल बनाया जिसमें Windows को ऐसी परिस्थितियों में resilient बनाने के लिए प्रोत्साहन—यानी लाभ और प्रतिस्पर्धा—की कमी है
    workstation computing क्षेत्र में Microsoft की स्थिति व्यावहारिक रूप से monopoly जैसी है, और अब यह infrastructure के करीब है, इसलिए उसके product की security, reliability और functionality सुनिश्चित करने की duty of care है
    प्रतिस्पर्धा न होने से Microsoft ने Windows innovation से हाथ खींच लिया, और इनमें से कुछ innovations शायद इस outage को रोक सकते थे। उदाहरण के लिए, CrowdStrike macOS और Linux पर user space में चलता है, तो क्या Windows CrowdStrike को user space में चलने के लिए जरूरी capabilities नहीं दे सकता?
    application sandboxing में innovation से शायद CrowdStrike को जिस स्तर के control की जरूरत होती है, उसे कम नहीं किया जा सकता था?
    Microsoft के पास दुनिया के computing infrastructure की चाबियां लगभग बिना प्रतिस्पर्धा के हैं और oversight भी बहुत कम है। Windows कभी Microsoft revenue का 80% से ज्यादा था, लेकिन अब लगभग 10% तक गिर गया है
    private company का पैसे के पीछे जाना कोई समस्या नहीं है, लेकिन अगर product अस्पतालों, airlines और critical infrastructure के संचालन के लिए जरूरी है, तो profitability बढ़ाने के लिए केवल AI assistants और ads पर अटके नहीं रहा जा सकता
    मेरे हिसाब से Microsoft ने consumers के प्रति अपनी duty of care छोड़ दी, और CrowdStrike उसका symptom है। सरकार को desktop workspace market में competition को गंभीरता से बढ़ावा देना चाहिए, या फिर Microsoft Windows products को regulate करना चाहिए

    • सही है। यह कई fronts पर failure है, और दशकों से चली आ रही systemic corruption का संकेत है
      Windows revenue share गिरने का एक फायदा यह है कि शायद MS अब Windows को ऐसी पवित्र चीज मानकर नहीं पकड़े रहेगा जिसे छुआ नहीं जा सकता

  • मैं CrowdStrike सीधे इस्तेमाल नहीं करता, और जहां तक मुझे पता है, मैंने इसे अपने system पर कभी install नहीं किया। पिछली company device पर शायद कुछ ऐसा चल रहा था, इसलिए अगर मैं गलत हूं तो सुधार दें
    CS driver पहले install होता है और हटाया नहीं जा सकता, शायद remote monitor इसे detect करता है, और signed driver होने की वजह से tampering मुश्किल बनाने के लिए काफी प्रयास किए गए लगते हैं
    लेकिन क्या वह driver कोई unsigned data file load करता है जिसे end user मनमर्जी से delete कर सकता है? क्या end user ऐसी file मनमर्जी से add करके driver से ऐसे तरीके से काम करवा सकता है जैसे उसे नहीं करना चाहिए?
    मुझे यह जानना है कि किसी malicious actor को malicious data file का इस्तेमाल करके एक और बड़े पैमाने का outage कराने से, या उससे भी बदतर kernel privileges पाने से, क्या रोकता है

    • ये files admin privileges होने पर भी user द्वारा delete या modify नहीं की जा सकतीं। अगर ऐसा संभव हो, तो antivirus बंद करना बहुत आसान हो जाएगा
      यह तभी संभव है जब file system को किसी दूसरे operating system से mount किया जाए, लेकिन आम तौर पर BitLocker उसे रोक देता है

  • क्या CrowdStrike customers के पास ऐसी updates जारी होने पर कोई say होता है, या वे बस यह स्वीकार करते हैं कि CrowdStrike को enterprise की सभी machines पर complete remote code execution मिल जाए
    कम से कम certificate authorities और cryptography वाले लोग तो उम्मीद करते हैं कि वे ऐसी चीजों को अपने systems से बाहर रख सकें

    • मुझे नहीं पता कि CrowdStrike जैसे third party को continuous endpoint security outsource करते हुए, जिन endpoints को protect करना है उन सभी पर remote code execution और ring 0 privileges दिए बिना कोई तरीका है या नहीं
      CrowdStrike द्वारा उस हिस्से को automate करना ही product का core है
    • हमारे lifetime में self-driving cars की automatic update से लाखों लोगों की मौत होगी
      शायद हम उसे देख भी न पाएं। क्योंकि हम उन लाखों में से एक हो सकते हैं
    • “content”, यानी किसे malware माना जाए, उसके automatic updates जरूरी हैं और update delay options को bypass करते हैं: https://twitter.com/patrickwardle/status/1814367918425079934

  • मैं जानना चाहूंगा कि क्या किसी को पता है कि यह “channel file” CS driver द्वारा sign और verify की जाती है या नहीं। अगर नहीं, तो यह ring 0 rootkit तक जाने वाला बड़ा hole लगता है
    channel file install करने के लिए privileges चाहिए होंगे, लेकिन एक बार यह संभव हो जाए तो system के कहीं ज्यादा अंदर छिपा जा सकता है। अगर channel file segmentation fault करा सकती है, तो शायद वह और भी बहुत कुछ कर सकती है
    इतने ऊंचे privilege पर चलने वाली चीज में जाने वाले हर input की कम से कम integrity check होनी चाहिए। यह basic है। सिर्फ यह तथ्य कि channel file delete की जा सकती है, यह संकेत देता है कि tamper-proofing mechanism भी नहीं है