70% de sekurecaj problemoj en Chromium estas kaŭzitaj de memoreraroj

Programistoj de la projekto Chromium analizita 912 altriskaj kaj kritikaj vundeblecoj identigitaj en stabilaj eldonoj de Chrome ekde 2015, kaj konkludis, ke 70% el ili estis kaŭzitaj de memormalsekureco (eraroj dum laborado kun montriloj en C/C++-kodo). Duono de ĉi tiuj problemoj (36.1%) estas kaŭzitaj de aliroj al la bufro post liberigo de la memoro asociita kun ĝi (use-post-libera).

70% de sekurecaj problemoj en Chromium estas kaŭzitaj de memoreraroj

Al la desegni Chromium estis komence kuŝis, ke eblas ke eraroj aperu en la kodo, do granda emfazo estis metita sur la uzo de sablokesto-izolado por limigi la sekvojn de vundeblecoj. Nuntempe, la eblecoj uzi ĉi tiun teknologion atingis la limon de siaj kapabloj kaj plia fragmentiĝo en procezoj estas nepraktika el la vidpunkto de la konsumo de rimedoj.

Por konservi la sekurecon de la kodbazo, Guglo ankaŭ devigas "regulo de du", laŭ kiu ĉiu aldonita kodo devas plenumi ne pli ol du el tri kondiĉoj: labori kun nevalidigitaj enigdatenoj, uzi nesekuran programlingvon (C/C++) kaj funkcii kun altigitaj privilegioj. Ĉi tiu regulo implicas, ke la kodo por prilaborado de eksteraj datumoj devas aŭ esti reduktita al minimumaj privilegioj (izolitaj) aŭ skribita en sekura programlingvo.

Por plue plibonigi la sekurecon de la kodbazo, projekto estis lanĉita por malhelpi memorerarojn de aperado en la kodbazo. Estas tri ĉefaj aliroj: krei C++-bibliotekojn kun funkcioj por sekura funkciado de memoro kaj vastigi la amplekson de la rubkolektanto, uzante aparatarprotektajn mekanismojn. MTE (Memory Tagging Extension) kaj skribaj komponantoj en lingvoj, kiuj certigas sekuran laboron kun memoro (Java, Kotlin, JavaScript, Rust, Swift).

Estas atendite ke laboro estos koncentrita en du areoj:

  • Signifa ŝanĝo al la evoluprocezo C++, kiu ne ekskludas negativan efikon al agado (aldonaj limkontroloj kaj rubkolekto). Anstataŭ krudaj montriloj, oni proponas uzi la tipon MiraclePtr, kiu permesas vin redukti ekspluateblajn uzpost-liberajn erarojn al kraŝoj, kiuj ne prezentas sekurecan minacon, sen rimarkinda negativa efiko al rendimento, memorkonsumo kaj stabileco.
  • La uzo de lingvoj dezajnitaj por plenumi memorajn sekurecajn kontrolojn ĉe kompila tempo (forigos la negativan efikon al rendimento propra de tiaj kontroloj dum koda ekzekuto, sed kondukos al pliaj kostoj por organizi la interago de kodo en nova lingvo kun kodo en C++).

Uzi memor-sekurajn bibliotekojn estas la plej simpla, sed ankaŭ malpli efika maniero. Reskribi kodon en Rust estas taksita kiel la plej efika, sed ankaŭ tre multekosta maniero.

70% de sekurecaj problemoj en Chromium estas kaŭzitaj de memoreraroj

fonto: opennet.ru

Aldoni komenton