Chromium-en segurtasun-arazoen % 70 memoria-akatsek eragiten dute

Chromium proiektuaren garatzaileak aztertu 912az geroztik Chrome-ren bertsio egonkorretan identifikatu ziren arrisku handiko eta ahultasun kritikoen 2015, eta horien % 70 memoriaren segurtasun ezaren ondorioz gertatu zela ondorioztatu zuten (erroreak C/C++ kodean erakusleekin lan egitean). Arazo horien erdia (% 36.1) harekin lotutako memoria askatu ondoren bufferra sartzeak (use-after-free) eragiten ditu.

Chromium-en segurtasun-arazoen % 70 memoria-akatsek eragiten dute

Chromium diseinatzerakoan hasieran izan zen ezarritabalitekeela kodean akatsak agertzea, beraz, enfasi handia jarri zen sandbox isolamendua erabiltzeari ahultasunen ondorioak mugatzeko. Gaur egun, teknologia hau erabiltzeko aukerak beren gaitasunen mugara iritsi dira eta prozesuetan gehiago zatitzea ezinezkoa da baliabideen kontsumoaren ikuspuntutik.

Kode-basearen segurtasuna mantentzeko, Google-k ere "biko araua", horren arabera, gehitutako edozein kodek hiru baldintza baino bi baino gehiago bete behar ditu: baliozkotu gabeko sarrerako datuekin lan egitea, programazio-lengoaia segurua (C/C++) erabiltzea eta pribilegio handiekin exekutatu. Arau honek esan nahi du kanpoko datuak prozesatzeko kodea gutxieneko pribilegioetara (isolatuta) murriztu behar dela edo programazio-lengoaia seguru batean idatzi behar dela.

Kode-oinarriaren segurtasuna are gehiago hobetzeko, memoria-akatsak kode-oinarrian ager ez daitezen proiektu bat abiarazi da. Hiru ikuspegi nagusi daude: memoriaren funtzionamendu segururako funtzioak dituzten C++ liburutegiak sortzea eta zabor biltzailearen esparrua zabaltzea, hardware babesteko mekanismoak erabiliz. MTE (Memory Tagging Extension) eta idazteko osagaiak memoriarekin lan segurua bermatzen duten hizkuntzetan (Java, Kotlin, JavaScript, Rust, Swift).

Lanak bi arlotan bideratuko direla aurreikusten da:

  • Aldaketa nabarmena C++ garapen prozesuan, eta horrek ez du baztertzen errendimenduan eragin negatiboa (muga-egiaztapen gehigarriak eta zabor bilketa). Erakusle gordinaren ordez, mota erabiltzea proposatzen da MirariPtr, ustiagarriak diren erabilera-doako erroreak segurtasun mehatxurik ez duten hutsegiteetara murrizteko aukera ematen duena, errendimenduan, memoria-kontsumoan eta egonkortasunean eragin negatibo nabarmenik gabe.
  • Konpilazio garaian memoriaren segurtasun-egiaztapenak egiteko diseinatutako lengoaiak erabiltzeak (kodearen exekuzioan egiaztapenek berezko duten errendimenduaren eragin negatiboa ezabatuko du, baina kostu gehigarriak ekarriko ditu kodearen interakzioa hizkuntza berri batean antolatzeko kodearekin). C++).

Memoria seguruko liburutegiak erabiltzea da modurik errazena, baina ez hain eraginkorrena ere. Rust-en kodea berridaztea modu eraginkorrena da, baina baita oso garestiena dela ere.

Chromium-en segurtasun-arazoen % 70 memoria-akatsek eragiten dute

Iturria: opennet.ru

Gehitu iruzkin berria