Project Zero ka zhvilluar një metodë për të shfrytëzuar dobësitë në Linux

Linux

Shfrytëzimi i referencave null në kernelin Linux

Kohët e fundit u njoftua se studiuesit nga ekipi i Google Project Zero kanë zhvilluar një metodë për të shfrytëzuar dobësitë në kernel Linux të shkaktuara nga çreferencimi i treguesit NULL.

Deri më tani, problemet e kernelit që lidhen me heqjen e referencës së treguesve NULL nuk kanë marrë vëmendjen e duhur , pasi konsiderohej jorealiste që probleme të tilla të shndërroheshin në sulme që çonin në përshkallëzimin e privilegjeve ose ekzekutimin e kodit të vet (ndalohet hartëzimi i proceseve të paprivilegjuara në rajonin e poshtëm të hapësirës së adresave).

Si rregull i përgjithshëm, gabime të tilla çojnë në gjenerimin e paralajmërimeve oops nga kerneli, pas të cilave detyrat problematike përfundojnë dhe gjendja rikthehet pa pasur nevojë të ndalet sistemi.

Metoda e re e sulmit bazohet në trajtimin e gjendjeve "oops" , të cilat mund të rezultojnë në një rritje të vlerës së numëruesit të referencës (refcount), gjë që nga ana tjetër mund të shkaktojë mbingarkesë të numëruesit dhe lirimin e memories së lidhur me refcount-in.

Në këtë rast, shfrytëzimi reduktohet në manipulime tipike të sulmeve të përdorimit pas pa pagesë (krihet një situatë ku numërimi i referencës së objektit bëhet zero, memoria çlirohet, por në fakt ka lidhje pune që tregojnë për memorien e çliruar).

Aktualisht, kur kerneli i Linux-it shkakton një dereferencë null nga brenda një konteksti procesi, ai gjeneron një gabim , i cili është i ndryshëm nga një panik kerneli. Një panik ndodh kur kerneli përcakton se nuk ka një mënyrë të sigurt për të vazhduar ekzekutimin dhe për këtë arsye duhet të ndërpresë të gjitha ekzekutimet. Megjithatë, kerneli nuk i ndal të gjitha ekzekutimet gjatë një gabimi ; në vend të kësaj, kerneli përpiqet të rikuperohet sa më mirë që të jetë e mundur dhe vazhdon ekzekutimin.

Çreferencimi i një treguesi NULL përdoret këtu si një mënyrë për të gjeneruar gjendjen "ops" në një mënyrë të kontrolluar. Problemi është se nevojiten rreth 232 thirrje statusi "oops" për të arritur një rimbursim 32-bitësh.

Nga një këndvështrim praktik, duhen afërsisht tetë ditë gjenerim të vazhdueshëm të gjendjeve jashtë vendit (OOP) për të kryer një sulm duke përdorur shfrytëzimin e propozuar. Nëse është i suksesshëm, shfrytëzimi ju lejon të ekzekutoni kodin tuaj në nivelin e bërthamës.

Referenca e treguesit NULL e përdorur në shfrytëzim u rregullua në tetor, por meqenëse çështje të ngjashme nuk janë të rralla dhe më parë trajtoheshin si gabime, jo dobësi, zhvilluesit do të shtojnë mbrojtje të përgjithshme në kernelin Linux për të parandaluar sulmet që manipulojnë gjenerimin e "oops ."

 Në rastin e një detyre, kjo do të thotë të hidhni poshtë pirgun ekzistues të kernelit dhe të shkoni direkt te make_task_dead që thërret do_exit. Kerneli gjithashtu do të postojë në dmesg një regjistër "përplasjeje" dhe një gjurmë kerneli që tregon se në çfarë gjendje ishte kerneli kur ndodhi gabimi. Kjo mund të duket si një zgjedhje e çuditshme kur ka ndodhur qartë dëmtimi i kujtesës; megjithatë, qëllimi është që të zbulohen më të lehta gabimet e kernelit dhe të regjistrohen sipas filozofisë se një sistem që funksionon është shumë më i lehtë për t'u korrigjuar sesa një sistem i dëmtuar.

Në veçanti , Kernel 6.2 përfshin ndryshime për të kufizuar numrin maksimal të "oops" . Pas arritjes së limitit, i cili është vendosur në 10 oops si parazgjedhje (mund ta ndryshoni këtë duke përdorur parametrin oops_limit nëse dëshironi), kerneli do të fillojë një kalim në një gjendje "paniku", të ndjekur nga një rinisje, e cila nuk do të lejojë numrin e përsëritjeve të kërkuara për të rivendosur refcount në zero.

Është planifikuar gjithashtu që kufizimi të transferohet në degët e kernelit të lëshuara më parë, por ende të mbështetura, si dhe paketat e kernelit të shpërndarjeve të njohura.

Së fundmi, nëse jeni të interesuar të mësoni më shumë rreth kësaj , mund t'i gjeni detajet në lidhjen e mëposhtme.


Shto si burim të preferuar në Google