لينڪس ڪرنل ۾ هڪ خطري (CVE-2022-42896) جي نشاندهي ڪئي وئي آهي، جيڪا ممڪن طور تي استعمال ڪري سگهجي ٿي ريموٽ ڪوڊ جي عمل کي منظم ڪرڻ لاءِ ڪنيل سطح تي بلوٽوت ذريعي خاص طور تي ٺهيل L2CAP پيڪٽ موڪلڻ سان. ان کان علاوه، L2022CAP هينڊلر ۾ هڪ ٻيو ساڳيو مسئلو (CVE-42895-2) جي نشاندهي ڪئي وئي آهي، جيڪا ترتيب جي معلومات سان پيڪيٽس ۾ ڪنيل ميموري مواد جي ليڪ ڪري سگهي ٿي. پهريون خطرو آگسٽ 2014 کان ظاهر ٿي رهيو آهي (ڪرنل 3.16)، ۽ ٻيو آڪٽوبر 2011 کان (ڪرنل 3.0). لينڪس ڪنيل رليز 6.1.0، 6.0.8، 4.9.333، 4.14.299، 4.19.265، 5.4.224، 5.10.154، ۽ 5.15.78 ۾ ڪمزورين کي خطاب ڪيو ويو آهي. توھان ھيٺ ڏنل صفحن تي تقسيم ۾ فيڪس کي ٽريڪ ڪري سگھو ٿا: Debian، Ubuntu، Gentoo، RHEL، SUSE، Fedora، Arch.
ريموٽ حملو ڪرڻ جي امڪان کي ظاهر ڪرڻ لاءِ، پروٽوٽائپ ڪارناما شايع ڪيا ويا آهن جيڪي Ubuntu 22.04 تي ڪم ڪن ٿا. حملي کي انجام ڏيڻ لاءِ، حملي آور کي بلوٽوٿ جي حد اندر هجڻ ضروري آهي- اڳي جوڙڻ جي ضرورت ناهي، پر ڪمپيوٽر تي بلوٽوٿ فعال هجڻ لازمي آهي. حملي لاءِ، مقتول جي ڊيوائس جي ميڪ ايڊريس کي ڄاڻڻ ڪافي آهي، جيڪو سنيفنگ ذريعي طئي ڪري سگهجي ٿو يا، ڪجهه ڊوائيسن تي، وائي فائي ميڪ ايڊريس جي بنياد تي ڳڻيو وڃي ٿو.
پهريون نقصان (CVE-2022-42896) l2cap_connect ۽ l2cap_le_connect_req افعال جي عمل ۾ اڳ ۾ ئي آزاد ٿيل ميموري ايريا (استعمال کان پوءِ-آزاد) تائين رسائي جي ڪري پيدا ٿيو آهي - new_connection ڪال بڪ ذريعي هڪ چينل ٺاهڻ کان پوءِ، هڪ تالا مقرر نه ڪيو ويو. ان لاءِ، پر هڪ ٽائمر مقرر ڪيو ويو هو (__set_chan_timer )، وقت ختم ٿيڻ تي، l2cap_chan_timeout فنڪشن کي ڪال ڪري ۽ l2cap_le_connect* فنڪشن ۾ چينل سان ڪم مڪمل ٿيڻ جي جانچ ڪرڻ کان سواءِ چينل کي صاف ڪرڻ.
ڊفالٽ ٽائيم آئوٽ 40 سيڪنڊ آهي ۽ اهو فرض ڪيو ويو ته اهڙي دير سان ريس جي حالت نه ٿي سگهي، پر اهو ظاهر ٿيو ته ايس ايم پي هينڊلر ۾ هڪ ٻي غلطي جي ڪري، ٽائمر کي فوري ڪال حاصل ڪرڻ ۽ حاصل ڪرڻ ممڪن هو. نسل جي حالت. l2cap_le_connect_req ۾ هڪ مسئلو ڪرينل ميموري ليڪ ٿي سگهي ٿو، ۽ l2cap_connect ۾ اهو ميموري جي مواد کي ختم ڪرڻ ۽ ان جي ڪوڊ تي عمل ڪرڻ جي ڪري سگھي ٿو. پهريون قسم جو حملو Bluetooth LE 4.0 (2009 کان وٺي) استعمال ڪندي ڪري سگهجي ٿو، ٻيو جڏهن Bluetooth BR/EDR 5.2 استعمال ڪندي (2020 کان وٺي).
ٻيو نقصان (CVE-2022-42895) l2cap_parse_conf_req فنڪشن ۾ هڪ بقايا ميموري ليڪ جي سبب آهي، جيڪو خاص طور تي ترتيب ڏنل ترتيبن جي درخواستن کي موڪلڻ ذريعي ڪنيل ڍانچي ڏانهن اشارو ڪندڙ جي باري ۾ دور دراز معلومات حاصل ڪرڻ لاء استعمال ڪري سگهجي ٿو. l2cap_parse_conf_req فنڪشن l2cap_conf_efs ڍانچي کي استعمال ڪيو، جنهن لاء مختص ڪيل ياداشت اڳ ۾ شروع نه ڪئي وئي هئي ۽ FLAG_EFS_ENABLE پرچم کي هٿي وٺائڻ سان اهو ممڪن هو ته پراڻي ڊيٽا کي پيڪ ۾ شامل ڪرڻ لاء اسٽيڪ کان. مسئلو صرف سسٽم تي ظاهر ٿئي ٿو جتي ڪنييل CONFIG_BT_HS اختيار سان ٺهيل آهي (ڊفالٽ طور تي غير فعال، پر ڪجهه تقسيم تي فعال، جهڙوڪ Ubuntu). هڪ ڪامياب حملي کي پڻ ترتيب ڏيڻ جي ضرورت آهي HCI_HS_ENABLED پيٽرولر کي مئنيجمينٽ انٽرفيس ذريعي صحيح (ڊفالٽ طور استعمال نه ڪيو ويو).
جو ذريعو: opennet.ru