د eBPF فرعي سیسټم کې زیان منونکي چې د لینکس کرنل په کچه د کوډ اجرا کولو ته اجازه ورکوي

د eBPF فرعي سیسټم کې دوه نوي زیانمنونکي پیژندل شوي، کوم چې تاسو ته اجازه درکوي د JIT سره په ځانګړي مجازی ماشین کې د لینکس کرنل دننه هینډلرونه پرمخ بوځي. دواړه زیانمننې دا ممکنه کوي چې ستاسو کوډ د کرنل حقونو سره اجرا کړئ، د جلا شوي eBPF مجازی ماشین څخه بهر. د ستونزو په اړه معلومات د صفر ورځې نوښت ټیم لخوا خپاره شوي ، کوم چې د Pwn2Own سیالي پرمخ وړي ، پدې کال کې په اوبنټو لینکس کې درې بریدونه وښودل شول چې دمخه نامعلوم زیانونه یې کارولي وو (ایا په eBPF کې زیانونه له دې بریدونو سره تړاو لري راپور نه دی ورکړل شوی) .

  • CVE-2021-3490 - زیانمنتیا په eBPF ALU32 کې د bitwise AND, OR, او XOR عملیات ترسره کولو پرمهال د 32-bit څخه بهر د چیک کولو نشتوالي له امله رامینځته کیږي. برید کوونکی کولی شي د دې غلطۍ څخه ګټه پورته کړي ترڅو د تخصیص شوي بفر له حدودو بهر ډاټا لوستل او لیکل وکړي. د XOR عملیاتو سره ستونزه د کرنل نسخه 5.7-rc1 څخه پیل کیږي، او AND او OR - د 5.10-rc1 څخه پیل کیږي.
  • CVE-2021-3489 - زیانمنتیا د رینګ بفر په پلي کولو کې د یوې تېروتنې له امله رامینځته شوې او د دې حقیقت له امله ده چې د bpf_ringbuf_reserve فعالیت دا احتمال نه دی چیک کړی چې د تخصیص شوي حافظې ساحې اندازه ممکن د اصلي اندازې څخه کم وي. د ringbuf څخه. ستونزه د 5.8-rc1 خوشې کیدو راهیسې څرګندیږي.

په توزیع کې د پیچلو زیانونو حالت په دې پاڼو کې تعقیب کیدی شي: اوبنټو، دیبیان، RHEL، فیډورا، SUSE، آرچ). فکسونه د پیچونو په توګه هم شتون لري (CVE-2021-3489, CVE-2021-3490). ایا دا مسله کارول کیدی شي پدې پورې اړه لري چې ایا د eBPF سیسټم کال کارونکي ته د لاسرسي وړ دی. د مثال په توګه، په RHEL کې په ډیفالټ ترتیب کې، د زیان مننې استخراج کارونکي ته اړتیا لري چې د CAP_SYS_ADMIN حقونه ولري.

په جلا توګه، موږ کولی شو په لینکس کرنل کې یو بل زیان په ګوته کړو - CVE-2021-32606، کوم چې محلي کاروونکي ته اجازه ورکوي چې خپل امتیازات د ریښې کچې ته لوړ کړي. ستونزه د لینکس کرنل 5.11 راهیسې څرګنده شوې او د CAN ISOTP پروتوکول پلي کولو کې د ریس حالت له امله رامینځته شوې ، کوم چې د isotp_setsockopt() فنکشن کې د مناسب لاکونو تنظیم کولو نشتوالي له امله د ساکټ پابند پیرامیټرو بدلول امکان لري. کله چې د CAN_ISOTP_SF_BROADCAST بیرغ پروسس کول.

وروسته له دې چې د ISOTP ساکټ بند شو، د ترلاسه کونکي ساکټ ته پابند پاتې کیږي، کوم چې کولی شي د ساکټ سره تړلي جوړښتونو کارولو ته دوام ورکړي وروسته له دې چې د دوی سره تړلې حافظه آزاده شي (استعمال وروسته - وړیا د isotp_sock جوړښت ته د زنګ له امله. چې دمخه آزاد شوی کله چې isotp_rcv() ویل کیږي). د معلوماتو د مینځلو له لارې، تاسو کولی شئ د sk_error_report() فنکشن ته اشاره وکړئ او خپل کوډ د کرنل په کچه اجرا کړئ.

سرچینه: opennet.ru

Add a comment