हाल ही में हम यहां उस ब्लॉग पर साझा करते हैं, जिसमें Microsoft ने रुचि दिखाई है उपतंत्र के बारे में ईबीपीएफ, चूंकि इसने विंडोज के लिए एक सबसिस्टम बनाया है जो अमूर्त व्याख्या स्थिर विश्लेषण पद्धति का उपयोग करता है, जो कि लिनक्स के लिए ईबीपीएफ चेकर की तुलना में कम झूठी सकारात्मक दर प्रदर्शित करता है, लूप विश्लेषण का समर्थन करता है, और अच्छी मापनीयता प्रदान करता है।
यह विधि मौजूदा eBPF कार्यक्रमों के विश्लेषण से प्राप्त कई विशिष्ट प्रदर्शन पैटर्न को ध्यान में रखती है। यह EBPF सबसिस्टम है लिनक्स कर्नेल में संस्करण 3.18 और के बाद से शामिल किया गया है यह आपको इनकमिंग / आउटगोइंग नेटवर्क पैकेट, फॉरवर्डिंग पैकेट, कंट्रोलिंग बैंडविड्थ, इंटरसेप्टिंग सिस्टम कॉल, एक्सेस कंट्रोल और ट्रैकिंग को प्रोसेस करने की अनुमति देता है।
और क्या वह इसके बारे में बात कर रहा है, यह हाल ही में पता चला था कि दो नई कमजोरियों की पहचान की गई है उपतंत्र में eBPF, जो आपको एक विशेष JIT वर्चुअल मशीन में Linux कर्नेल के अंदर ड्राइवर चलाने की अनुमति देता है।
दोनों कमजोरियाँ कर्नेल अधिकारों के साथ कोड चलाने का अवसर प्रदान करती हैं, पृथक EBPF वर्चुअल मशीन के बाहर।
जानकारी समस्याओं के बारे में जीरो डे इनिशिएटिव टीम द्वारा प्रकाशित किया गया था, जो Pwn2Own प्रतियोगिता चलाता है, जिसके दौरान इस वर्ष उबंटू लिनक्स पर तीन हमलों का प्रदर्शन किया गया था, जिसमें पहले अज्ञात कमजोरियों का उपयोग किया गया था (यदि ईएफ़पीएफ में भेद्यता इन हमलों से संबंधित है तो इसकी सूचना नहीं है)।
eBPF ALU32 बिटवाइज़ ऑपरेशंस (AND, OR and .) के लिए ट्रैकिंग की सीमा तय करता है XOR) 32-बिट सीमाएं अपडेट नहीं की गईं।
उसके साथ काम कर रहे RedRocket CTF टीम (@redrocket_ctf) के मैनफ्रेड पॉल (@_manfp)ट्रेंड माइक्रो की जीरो डे पहल ने पाया कि यह भेद्यता इसे कर्नेल में पढ़े और लिखने वाले आउट-ऑफ-बाउंड में परिवर्तित किया जा सकता है। यह किया गया है ZDI-CAN-13590 और असाइन किए गए CVE-2021-3490 के रूप में रिपोर्ट किया गया।
- सीवीई-2021-3490: eBPF ALU32 पर बिटवाइज़ AND, OR, और XOR संचालन करते समय 32-बिट मानों के लिए आउट-ऑफ-बाउंड सत्यापन की कमी के कारण भेद्यता है। एक हमलावर आवंटित बग की सीमाओं के बाहर डेटा को पढ़ने और लिखने के लिए इस बग का लाभ उठा सकता है। XOR के संचालन में समस्या कर्नेल 5.7-rc1, और AND के बाद से लगभग 5.10-rc1 के बाद से है।
- सीवीई-2021-3489: भेद्यता रिंग बफर कार्यान्वयन में एक बग के कारण होती है और इस तथ्य से संबंधित है कि bpf_ringbuf_reserve फ़ंक्शन ने इस संभावना की जांच नहीं की कि आवंटित मेमोरी क्षेत्र का आकार रिंगरोड बफर के वास्तविक आकार से छोटा है। 5.8-आरसी 1 की रिहाई के बाद से समस्या स्पष्ट हो गई है।
इसके अलावा, हम लिनक्स कर्नेल में एक और भेद्यता भी देख सकते हैं: सीवीई-2021-32606, जो एक स्थानीय उपयोगकर्ता को अपने विशेषाधिकारों को जड़ स्तर तक बढ़ाने की अनुमति देता है। समस्या लिनक्स कर्नेल 5.11 के बाद से ही प्रकट होती है और CAN ISOTP प्रोटोकॉल के कार्यान्वयन में दौड़ की स्थिति के कारण होती है, जो i में उचित तालों के कॉन्फ़िगरेशन की कमी के कारण सॉकेट बाइंडिंग मापदंडों को बदलना संभव बनाता है।sotp_setsockopt () जब ध्वज संसाधित होता है CAN_ISOTP_SF_BROADCAST.
एक बार सॉकेट, ISOTP रिसीवर सॉकेट के लिए बाध्य करना जारी रखता है, जो संबंधित मेमोरी के मुक्त होने के बाद सॉकेट से जुड़े संरचनाओं का उपयोग करना जारी रख सकता है (संरचना कॉल के कारण उपयोग के बाद मुक्त) isotp_sock पहले से ही जारी जब मैं फोनsotp_rcv()। डेटा में हेरफेर करके, आप पॉइंटर को फ़ंक्शन में ओवरराइड कर सकते हैं sk_error_report () और कर्नेल स्तर पर अपना कोड चलाएं।
वितरण में कमजोरियों के लिए सुधार की स्थिति इन पृष्ठों पर नज़र रखी जा सकती है: Ubuntu, डेबियन, RHEL, फेडोरा, SUSE, मेहराब).
सुधार पैच के रूप में भी उपलब्ध हैं (CVE-2021-3489 और CVE-2021-3490)। समस्या का दोहन उपयोगकर्ता के लिए eBPF सिस्टम पर कॉल की उपलब्धता पर निर्भर करता है। उदाहरण के लिए, आरएचईएल पर डिफ़ॉल्ट कॉन्फ़िगरेशन में, भेद्यता का फायदा उठाने के लिए उपयोगकर्ता को CAP_SYS_ADMIN विशेषाधिकारों की आवश्यकता होती है।
अंत में यदि आप इसके बारे में अधिक जानना चाहते हैं, आप विवरण देख सकते हैं निम्नलिखित लिंक में