Vulnerabileco estis identigita en la Android-platformo (CVE-2022-20465), kiu ebligas al vi malŝalti la ekranan seruron rearanĝante la SIM-karton kaj enigante la PUK-kodon. La kapablo malŝalti la seruron estis pruvita sur Google Pixel-aparatoj, sed ĉar la riparo influas la ĉefan Android-kodbazon, verŝajne la problemo influas firmvaron de aliaj fabrikistoj. La problemo estas traktita en la novembra lanĉo de Android-sekureca flikaĵo. La esploristo, kiu atentigis la problemon, ricevis rekompencon de $ 70 mil de Guglo.
La problemo estas kaŭzita de malĝusta malŝlosa pretigo post enigo de la PUK-kodo (Persona Malbloka Ŝlosilo), kiu estas uzata por rekomenci funkciadon de SIM-karto, kiu estis blokita post plurfoje enigo de la PIN-kodo malĝuste. Por malŝalti la ekranan ŝlosilon, simple instalu vian SIM-karton en via telefono, kiu havas PIN-kodan protekton. Post ŝanĝo de SIM-karto protektita per PIN-kodo, peto de PIN-kodo unue aperas sur la ekrano. Se vi enmetas la PIN-kodon malĝuste trifoje, la SIM-karto estos blokita, post kio vi havos la ŝancon enigi la PUK-kodon por malŝlosi ĝin. Evidentiĝis, ke ĝuste enigi la PUK-kodon ne nur malŝlosas la SIM-karton, sed kondukas al transiro al la ĉefa interfaco, preterirante la ekranŝparilon, sen konfirmi aliron per la ĉefa pasvorto aŭ ŝablono.
La vundebleco estas kaŭzita de eraro en la logiko por kontroli PUK-kodojn en la prizorganto de KeyguardSimPukViewController, kiu respondecas pri montri la kroman aŭtentikan ekranon. Android uzas plurajn specojn de aŭtentigaj ekranoj (por PIN, PUK, pasvorto, ŝablono, biometria aŭtentikigo) kaj tiuj ekranoj estas nomitaj sinsekve kiam pluraj kontroloj devas esti faritaj, ekzemple, kiam PIN kaj ŝablono estas postulataj.
Se vi enmetas la PIN-kodon ĝuste, la dua etapo de konfirmo estas ekigita, postulante vin enigi la ĉefan malŝlosan kodon, sed kiam vi enigas la PUK-kodon, ĉi tiu etapo estas preterlasita kaj aliro estas koncedita sen peti la ĉefan pasvorton aŭ ŝablonon ŝlosilon. . La sekva malŝlosa etapo estas forĵetita ĉar kiam oni vokas KeyguardSecurityContainerController#dismiss() ne estas komparo inter la atendataj kaj pasitaj konfirmmetodoj, t.e. la procesoro kredas, ke la konfirmmetodo ne ŝanĝiĝis kaj la kompletigo de la PUK-koda konfirmo indikas sukcesan konfirmon de aŭtoritato.
La vundebleco estis malkovrita hazarde - la telefono de la uzanto estis morta kaj post ŝargi kaj ŝalti ĝin, li faris eraron plurfoje enirante la PIN-kodon, post kio li malŝlosis ĝin per la PUK-kodo kaj surpriziĝis, ke la sistemo ne demandis. por la ĉefa pasvorto uzata por malĉifri la datumojn, post kio ĝi frostiĝis kun mesaĝo "Pixel komencas...". La uzanto montriĝis zorgema, decidis eltrovi kio okazas kaj komencis eksperimenti kun enigo de PIN kaj PUK-kodoj en malsamaj manieroj, ĝis li hazarde forgesis rekomenci la aparaton post ŝanĝi la SIM-karton kaj akiris aliron al la medio anstataŭe de. frostiĝanta.
Aparte interesa estas la reago de Guglo al la anonco pri vundebleco. Informoj pri la problemo estis senditaj en junio, sed ĝis septembro la esploristo ankoraŭ ne povis akiri klaran respondon. Li kredis, ke ĉi tiu konduto estis klarigita per la fakto, ke li ne estis la unua, kiu raportis ĉi tiun eraron. Suspektoj, ke io misfunkcias, ekestis en septembro, kiam la problemo restis nekorektita post instalo de firmware-ĝisdatigo publikigita 90 tagojn poste, kiam la deklarita nediskoniga periodo jam eksvalidiĝis.
Ĉar ĉiuj provoj ekscii la staton de la sendita mesaĝo pri la problemo nur kaŭzis aŭtomatigitajn kaj ŝablonajn respondojn, la esploristo provis kontakti dungitojn de Google persone por klarigi la situacion per la preparado de riparo kaj eĉ pruvis la vundeblecon en la Londona oficejo de Google. . Nur post tio funkciis por forigi la vundeblecon antaŭeniri. Dum la analizo, montriĝis, ke iu jam antaŭe raportis la problemon, sed Guglo decidis fari escepton kaj pagi rekompencon pro raportado de la problemo denove, ĉar nur danke al la persisto de sia aŭtoro la problemo estis rimarkita.
fonto: opennet.ru