د Android پلیټ فارم (CVE-2022-20465) کې یو زیان په ګوته شوی ، کوم چې تاسو ته اجازه درکوي د سیم کارت بیا تنظیم کولو او د PUK کوډ دننه کولو سره د سکرین لاک غیر فعال کړئ. د لاک غیر فعال کولو وړتیا د ګوګل پکسل وسیلو کې ښودل شوي ، مګر له هغه وخته چې فکس د Android اصلي کوډبیس اغیزه کوي ، احتمال لري چې ستونزه د نورو تولید کونکو فرم ویئر اغیزه وکړي. مسله د نومبر په Android امنیت پیچ رول آوټ کې په ګوته شوې. هغه څیړونکي چې دې ستونزې ته یې پام اړولی د ګوګل لخوا 70 زره ډالر انعام ترلاسه کړ.
ستونزه د PUK کوډ (Personal Unblocking Key) داخلولو وروسته د ناسم خلاصولو پروسس کولو له امله رامینځته کیږي ، کوم چې د سیم کارت د بیا پیلولو لپاره کارول کیږي چې د بار بار د PIN کوډ غلط داخلولو وروسته بلاک شوی. د سکرین لاک غیر فعالولو لپاره ، یوازې خپل سیم کارت په خپل تلیفون کې نصب کړئ ، کوم چې د PIN کوډ محافظت لري. د PIN کوډ لخوا خوندي شوي سیم کارت بدلولو وروسته ، د PIN کوډ غوښتنه لومړی په سکرین کې ښودل کیږي. که تاسو درې ځله په غلط ډول د PIN کوډ داخل کړئ، سیم کارت به بند شي، له هغې وروسته به تاسو ته فرصت درکړل شي چې د خلاصولو لپاره PUK کوډ دننه کړئ. دا معلومه شوه چې په سمه توګه د PUK کوډ داخلول نه یوازې سیم کارت خلاصوي ، بلکه اصلي انٹرفیس ته د لیږد لامل کیږي ، د سکرین سیور په واسطه ، پرته له دې چې د اصلي پاسورډ یا نمونې په کارولو سره لاسرسي تایید کړي.
زیانمنتیا د KeyguardSimPukViewController هینډلر کې د PUK کوډونو چک کولو لپاره په منطق کې د غلطۍ له امله رامینځته کیږي، کوم چې د اضافي تصدیق سکرین ښودلو مسولیت لري. Android د تصدیق کولو څو ډوله سکرینونه کاروي (د PIN، PUK، پاسورډ، نمونې، بایومتریک تصدیق لپاره) او دا سکرینونه په ترتیب سره ویل کیږي کله چې ډیری چکونو ته اړتیا وي، د بیلګې په توګه، کله چې یو PIN او نمونه اړین وي.
که تاسو د PIN کوډ په سمه توګه دننه کړئ، د تایید دوهم پړاو پیل کیږي، تاسو اړتیا لرئ چې د اصلي انلاک کوډ داخل کړئ، مګر کله چې تاسو د PUK کوډ داخل کړئ، دا مرحله پریښودل کیږي او د اصلي پاسورډ یا نمونې کیلي غوښتنه کولو پرته لاسرسی ورکول کیږي. . د انلاک کولو راتلونکی مرحله له مینځه وړل کیږي ځکه چې کله د KeyguardSecurityContainerController#dismiss() زنګ ووهئ د تمه شوي او تایید شوي تایید میتودونو ترمینځ هیڅ پرتله نشته، د بیلګې په توګه. پروسیسر باور لري چې د تایید کولو طریقه نه ده بدله شوې او د PUK کوډ تایید بشپړول د واک بریالي تایید په ګوته کوي.
زیان په ناڅاپي ډول کشف شو - د کارونکي تلیفون مړ و او د چارج کولو او آن کولو وروسته یې د PIN کوډ دننه کولو کې څو ځله خطا وکړه ، وروسته یې هغه د PUK کوډ سره خلاص کړ او حیران شو چې سیسټم یې پوښتنه نه کوي. د اصلي پټنوم لپاره چې د ډیټا ډیکریټ کولو لپاره کارول کیږي ، وروسته له هغه چې دا د پیغام سره کنګل شو "پکسل پیل کیږي ...". کارونکی دقیق وګرځید ، پریکړه یې وکړه چې معلومه کړي چې څه پیښیږي او په بیلابیلو لارو یې د PIN او PUK کوډونو داخلولو تجربه پیل کړه ، تر هغه چې هغه په تصادفي ډول د سیم کارت بدلولو وروسته د وسیله ریبوټ کول هیر کړل او پرځای یې چاپیریال ته لاسرسی وموند. یخ
د زیان مننې اعلان ته د ګوګل عکس العمل په ځانګړې توګه دلچسپي ده. د ستونزې په اړه معلومات د جون په میاشت کې لیږل شوي، مګر تر سپتمبر پورې څیړونکي لا تر اوسه د روښانه ځواب ترلاسه کولو توان نه درلود. هغه باور درلود چې دا چلند د دې حقیقت له مخې تشریح شوی چې هغه لومړی نه و چې د دې تېروتنې راپور ورکړي. شکونه چې یو څه غلط روان و د سپتمبر په میاشت کې راپورته شو، کله چې ستونزه د 90 ورځو وروسته خپاره شوي د فرم ویئر تازه نصبولو وروسته سم پاتې نه شوه، کله چې د نه افشا کولو موده پای ته رسیدلې وه.
څرنګه چې د ستونزې په اړه د لیږل شوي پیغام د وضعیت موندلو ټولې هڅې یوازې د اتوماتیک او ټیمپلیټ ځوابونو لامل شوي، څیړونکي هڅه وکړه چې د ګوګل کارمندانو سره په شخصي توګه اړیکه ونیسي ترڅو وضعیت د حل چمتو کولو سره روښانه کړي او حتی د ګوګل لندن دفتر کې زیانمنتیا ښودلې. . یوازې وروسته له دې چې د زیان مننې له منځه وړلو لپاره کار ترسره شو مخ په وړاندې ځي. د تحلیل په جریان کې، دا معلومه شوه چې یو چا دمخه د ستونزې راپور ورکړی و، مګر ګوګل پریکړه وکړه چې یو استثنا رامنځته کړي او بیا د ستونزې راپور ورکولو لپاره انعام ورکړي، ځکه چې دا یوازې د لیکوال د دوام څخه مننه وه چې ستونزه یې لیدل شوې وه.
سرچینه: opennet.ru