ലോക്ക് സ്‌ക്രീൻ മറികടക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന Android-ലെ അപകടസാധ്യത

സിം കാർഡ് പുനഃക്രമീകരിച്ച് PUK കോഡ് നൽകി സ്‌ക്രീൻ ലോക്ക് പ്രവർത്തനരഹിതമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ആൻഡ്രോയിഡ് പ്ലാറ്റ്‌ഫോമിൽ (CVE-2022-20465) ഒരു അപകടസാധ്യത തിരിച്ചറിഞ്ഞു. ലോക്ക് പ്രവർത്തനരഹിതമാക്കാനുള്ള കഴിവ് ഗൂഗിൾ പിക്സൽ ഉപകരണങ്ങളിൽ പ്രകടമാക്കിയിട്ടുണ്ട്, എന്നാൽ ഈ പരിഹാരം പ്രധാന ആൻഡ്രോയിഡ് കോഡ്ബേസിനെ ബാധിക്കുന്നതിനാൽ, പ്രശ്നം മറ്റ് നിർമ്മാതാക്കളിൽ നിന്നുള്ള ഫേംവെയറിനെ ബാധിക്കാൻ സാധ്യതയുണ്ട്. നവംബറിലെ ആൻഡ്രോയിഡ് സെക്യൂരിറ്റി പാച്ച് റോൾഔട്ടിൽ ഈ പ്രശ്നം അഭിസംബോധന ചെയ്തിട്ടുണ്ട്. പ്രശ്നം ശ്രദ്ധയിൽപ്പെടുത്തിയ ഗവേഷകന് Google-ൽ നിന്ന് $70 പ്രതിഫലം ലഭിച്ചു.

PUK കോഡ് (വ്യക്തിഗത അൺബ്ലോക്കിംഗ് കീ) നൽകിയതിന് ശേഷം തെറ്റായ അൺലോക്കിംഗ് പ്രോസസ്സിംഗ് മൂലമാണ് പ്രശ്‌നം ഉണ്ടാകുന്നത്, ഇത് PIN കോഡ് ആവർത്തിച്ച് തെറ്റായി നൽകിയതിന് ശേഷം ബ്ലോക്ക് ചെയ്യപ്പെട്ട ഒരു സിം കാർഡിന്റെ പ്രവർത്തനം പുനരാരംഭിക്കാൻ ഉപയോഗിക്കുന്നു. സ്‌ക്രീൻ ലോക്ക് പ്രവർത്തനരഹിതമാക്കാൻ, പിൻ കോഡ് പരിരക്ഷയുള്ള ഫോണിൽ സിം കാർഡ് ഇൻസ്റ്റാൾ ചെയ്യുക. ഒരു പിൻ കോഡ് ഉപയോഗിച്ച് പരിരക്ഷിച്ചിട്ടുള്ള ഒരു സിം കാർഡ് മാറ്റിയ ശേഷം, ഒരു പിൻ കോഡ് അഭ്യർത്ഥന ആദ്യം സ്ക്രീനിൽ ദൃശ്യമാകും. നിങ്ങൾ മൂന്ന് തവണ PIN കോഡ് തെറ്റായി നൽകിയാൽ, സിം കാർഡ് ബ്ലോക്ക് ചെയ്യപ്പെടും, അതിനുശേഷം അത് അൺലോക്ക് ചെയ്യാൻ PUK കോഡ് നൽകാനുള്ള അവസരം നിങ്ങൾക്ക് നൽകും. PUK കോഡ് ശരിയായി നൽകുന്നത് സിം കാർഡ് അൺലോക്ക് ചെയ്യുക മാത്രമല്ല, പ്രധാന പാസ്‌വേഡോ പാറ്റേണോ ഉപയോഗിച്ച് ആക്‌സസ് സ്ഥിരീകരിക്കാതെ സ്‌ക്രീൻ സേവറിനെ മറികടന്ന് പ്രധാന ഇന്റർഫേസിലേക്കുള്ള പരിവർത്തനത്തിലേക്ക് നയിക്കുകയും ചെയ്യുന്നു.

അധിക പ്രാമാണീകരണ സ്‌ക്രീൻ പ്രദർശിപ്പിക്കുന്നതിന് ഉത്തരവാദിയായ KeyguardSimPukViewController ഹാൻഡ്‌ലറിലെ PUK കോഡുകൾ പരിശോധിക്കുന്നതിനുള്ള ലോജിക്കിലെ പിശകാണ് ഈ അപകടത്തിന് കാരണം. ആൻഡ്രോയിഡ് നിരവധി തരം പ്രാമാണീകരണ സ്‌ക്രീനുകൾ ഉപയോഗിക്കുന്നു (പിൻ, പിയുകെ, പാസ്‌വേഡ്, പാറ്റേൺ, ബയോമെട്രിക് പ്രാമാണീകരണം) കൂടാതെ ഒന്നിലധികം പരിശോധനകൾ നടത്തേണ്ടിവരുമ്പോൾ ഈ സ്‌ക്രീനുകളെ തുടർച്ചയായി വിളിക്കുന്നു, ഉദാഹരണത്തിന്, ഒരു പിൻ, പാറ്റേൺ എന്നിവ ആവശ്യമായി വരുമ്പോൾ.

നിങ്ങൾ PIN കോഡ് ശരിയായി നൽകിയാൽ, പ്രധാന അൺലോക്ക് കോഡ് നൽകേണ്ട രണ്ടാം ഘട്ട പരിശോധന ആരംഭിക്കും, എന്നാൽ നിങ്ങൾ PUK കോഡ് നൽകുമ്പോൾ, ഈ ഘട്ടം ഒഴിവാക്കുകയും പ്രധാന പാസ്‌വേഡോ പാറ്റേൺ കീയോ ആവശ്യപ്പെടാതെ തന്നെ ആക്‌സസ് അനുവദിക്കുകയും ചെയ്യും. . KeyguardSecurityContainerController#dismiss() എന്ന് വിളിക്കുമ്പോൾ പ്രതീക്ഷിച്ചതും പാസ്സായതുമായ സ്ഥിരീകരണ രീതികൾ തമ്മിൽ താരതമ്യം ചെയ്യാത്തതിനാൽ അടുത്ത അൺലോക്കിംഗ് ഘട്ടം നിരസിച്ചു, അതായത്. സ്ഥിരീകരണ രീതി മാറിയിട്ടില്ലെന്നും PUK കോഡ് പരിശോധന പൂർത്തിയാക്കുന്നത് അധികാരത്തിന്റെ വിജയകരമായ സ്ഥിരീകരണത്തെ സൂചിപ്പിക്കുന്നുവെന്നും പ്രോസസർ വിശ്വസിക്കുന്നു.

അപകടസാധ്യത ആകസ്മികമായി കണ്ടെത്തി - ഉപയോക്താവിന്റെ ഫോൺ നിർജ്ജീവമാണ്, അത് ചാർജ് ചെയ്ത് ഓണാക്കിയ ശേഷം, പിൻ കോഡ് നൽകുമ്പോൾ അയാൾക്ക് നിരവധി തവണ തെറ്റ് സംഭവിച്ചു, അതിനുശേഷം അദ്ദേഹം അത് PUK കോഡ് ഉപയോഗിച്ച് അൺലോക്ക് ചെയ്യുകയും സിസ്റ്റം ചോദിക്കാത്തതിൽ ആശ്ചര്യപ്പെടുകയും ചെയ്തു. ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്യാൻ ഉപയോഗിക്കുന്ന പ്രധാന പാസ്‌വേഡിനായി, "പിക്സൽ ആരംഭിക്കുന്നു..." എന്ന സന്ദേശത്തോടെ അത് മരവിപ്പിച്ചു. സിം കാർഡ് മാറ്റിയതിന് ശേഷം ഉപകരണം റീബൂട്ട് ചെയ്യാൻ അബദ്ധവശാൽ മറക്കുകയും പകരം പരിസ്ഥിതിയിലേക്ക് പ്രവേശനം ലഭിക്കുകയും ചെയ്യുന്നത് വരെ, ഉപയോക്താവ് സൂക്ഷ്മതയുള്ളവനായി മാറി, എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാൻ തീരുമാനിക്കുകയും PIN, PUK കോഡുകൾ എന്നിവ വ്യത്യസ്ത രീതികളിൽ നൽകാനുള്ള പരീക്ഷണം ആരംഭിക്കുകയും ചെയ്തു. മരവിപ്പിക്കുന്നത്.

ദുർബലത പ്രഖ്യാപനത്തോടുള്ള Google-ന്റെ പ്രതികരണമാണ് പ്രത്യേക താൽപ്പര്യം. പ്രശ്നത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ ജൂണിൽ അയച്ചു, എന്നാൽ സെപ്റ്റംബർ വരെ ഗവേഷകന് വ്യക്തമായ ഉത്തരം നേടാൻ കഴിഞ്ഞില്ല. ഈ പിശക് റിപ്പോർട്ട് ചെയ്ത ആദ്യത്തെയാളല്ല എന്ന വസ്തുതയാണ് ഈ പെരുമാറ്റം വിശദീകരിക്കുന്നതെന്ന് അദ്ദേഹം വിശ്വസിച്ചു. 90 ദിവസത്തിന് ശേഷം പുറത്തിറക്കിയ ഫേംവെയർ അപ്‌ഡേറ്റ് ഇൻസ്റ്റാൾ ചെയ്തതിന് ശേഷവും പ്രശ്നം പരിഹരിക്കപ്പെടാതെ തുടർന്നപ്പോൾ, പ്രസ്താവിക്കാത്ത വെളിപ്പെടുത്തൽ കാലയളവ് ഇതിനകം കാലഹരണപ്പെട്ട സെപ്റ്റംബറിൽ എന്തോ കുഴപ്പം സംഭവിക്കുന്നു എന്ന സംശയം ഉയർന്നു.

പ്രശ്‌നത്തെക്കുറിച്ച് അയച്ച സന്ദേശത്തിന്റെ സ്റ്റാറ്റസ് കണ്ടെത്താനുള്ള എല്ലാ ശ്രമങ്ങളും ഓട്ടോമേറ്റഡ്, ടെംപ്ലേറ്റ് മറുപടികളിലേക്ക് നയിച്ചതിനാൽ, ഗവേഷകൻ ഗൂഗിൾ ജീവനക്കാരെ വ്യക്തിപരമായി ബന്ധപ്പെടാൻ ശ്രമിച്ചു, പ്രശ്‌നപരിഹാരം തയ്യാറാക്കി, ഗൂഗിളിന്റെ ലണ്ടൻ ഓഫീസിലെ അപകടസാധ്യത പ്രകടിപ്പിക്കുകയും ചെയ്തു. . ഇതിനുശേഷം മാത്രമാണ് അപകടസാധ്യത ഇല്ലാതാക്കുന്നതിനുള്ള പ്രവർത്തനങ്ങൾ മുന്നോട്ട് പോയത്. വിശകലനത്തിനിടയിൽ, ആരോ ഇതിനകം തന്നെ പ്രശ്നം റിപ്പോർട്ട് ചെയ്തിട്ടുണ്ടെന്ന് മനസ്സിലായി, പക്ഷേ ഒരു അപവാദം വരുത്താനും പ്രശ്നം വീണ്ടും റിപ്പോർട്ടുചെയ്യുന്നതിന് പ്രതിഫലം നൽകാനും Google തീരുമാനിച്ചു, കാരണം പ്രശ്നം ശ്രദ്ധയിൽപ്പെട്ടത് അതിന്റെ രചയിതാവിന്റെ സ്ഥിരോത്സാഹത്തിന് നന്ദി മാത്രമാണ്.

അവലംബം: opennet.ru