Chrome zero-day: »To izkoriščanje je v naravi«, zato zdaj preverite svojo različico

Chrome zero-day: »To izkoriščanje je v naravi«, zato zdaj preverite svojo različico

Časovni žig: 6. junij 2023 12:28
Izvorno vozlišče: 2704382
by Paul Ducklin

Izšla je najnovejša Googlova posodobitev za Chrome in tokrat podjetje ni zmanjševal besed o enem od dveh varnostnih popravkov, ki jih vključuje:

Google se zaveda, da izkoriščanje za CVE-2023-3079 obstaja v divjini.

Ni govora o dveh stopnjah ločevanja, kot smo ga prej pogosto videli pri Googlu, da bi rekli, da je podjetje »seznanjeno s poročili« o izkoriščanju.

Tokrat je »sami se zavedamo tega«, kar je še bolj naravnost prevedeno v »vemo, da sleparji to zlorabljajo, medtem ko govorimo«, glede na to, da je poročilo o napaki prišlo neposredno iz Googlove skupine za raziskovanje groženj.

Kot običajno to pomeni, da je Google preiskoval aktiven napad (ne vemo, ali proti samemu Googlu ali kakšni zunanji organizaciji), v katerem je Chrome zadela prej neznana varnostna luknja.

Napaka je preprosto opisana kot: Tipska zmeda v V8. (Razumljivo je, da Google na tej stopnji ne pove več kot to.)

Kot smo že pojasnili, a tip zmede napaka se zgodi, ko programu posredujete del podatkov, ki naj bi jih razčlenil, preveril, obdelal in ukrepal na en način ...

…vendar vam kasneje uspe pretentati program, da interpretira podatke na drugačen, nepooblaščen, nepreverjen in potencialno nevaren način.

Razložene nevarnosti zmede tipa

Predstavljajte si, da pišete program v C. (Ni pomembno, ali poznate C ali ne, vseeno lahko sledite.)

V C-ju navadno deklarirate spremenljivke posamezno, s čimer ne samo rezervirate pomnilnik, kamor jih lahko shranite, temveč tudi signalizirate programu, kako naj se te spremenljivke uporabljajo.

Na primer:

 long long int JulianDayNumber; signed char* CustomerName;

Prva deklaracija spremenljivke rezervira 64 bitov za shranjevanje navadne stare cele vrednosti, ki predstavlja številko astronomskega dne. (Če se sprašujete, je to popoldne JDN 23157 – julijanski dnevi se začnejo opoldne, ne opolnoči, ker astronomi pogosto delajo ponoči, polnoč pa je sredi njihovega delovnega dne.)

Drugi rezervira 64 bitov za shranjevanje pomnilniškega naslova, kjer je mogoče najti besedilni niz imena stranke.

Kot si lahko predstavljate, je bolje, da teh dveh vrednosti ne zamenjujete, ker številka, ki je smiselna in varna za uporabo kot številka dneva, na primer 23157, skoraj zagotovo ne bi bila varna za uporabo kot pomnilniški naslov.

Kot lahko vidite iz tega izpisa pomnilnika delujočega programa Windows, se najnižji pomnilniški naslov, ki je dodeljen za uporabo, začne pri 0x00370000, kar je 3,604,480 v decimalki, veliko več kot katero koli razumno število dneva.

Dejanski pomnilniški naslovi, ki jih uporablja Windows, se sčasoma naključno spreminjajo, da prevaranti težje uganejo vašo postavitev pomnilnika, tako da bi, če bi zagnali isti program, dobili vrednosti, vendar bodo kljub temu podobne:

In (čeprav ni na dnu zgornje slike) pomnilniške naslove razdelka z uporabniškimi podatki med izvajanjem, ko se je ta program izvajal iz 0x01130000 do 0x01134FFF, ki predstavlja malo verjeten datumski razpon od 22. julija 44631 do 16. avgusta 44687.

Dejansko, če poskušate pomešati ti dve spremenljivki, bi vas moral prevajalnik poskušati opozoriti, na primer takole:

 JulianDayNumber = Ime stranke; CustomerName = JulianDayNumber; opozorilo: dodelitev ustvari celo število iz kazalca brez pretvorbe opozorilo: dodelitev naredi kazalec iz celega števila brez pretvorbe

Zdaj, če ste kdaj programirali v C, boste vedeli, da lahko spremenljivke zaradi priročnosti deklarirate z več različnimi interpretacijami z uporabo union ključna beseda, kot je ta:

 unija { long long int JulianDayNumer; signed char* CustomerName; } podatki;

Zdaj se lahko na popolnoma isto spremenljivko v pomnilniku sklicujete na dva različna načina.

Če pišete data.JulianDayNumber, shranjene podatke čarobno interpretirate kot celo število, vendar pisanje data.CustomerName pove prevajalniku, da se sklicujete na pomnilniški naslov, čeprav dostopate do istih shranjenih podatkov.

To, kar počnete, bolj ali manj, je priznanje prevajalniku, da boste podatke, ki jih imate, včasih obravnavali kot datum, drugič pa kot pomnilniški naslov, in da prevzemate odgovornost, da si zapomnite, katera razlaga velja v katerem trenutku v kodi.

Morda se odločite za drugo spremenljivko, znano kot a tag (običajno celo število), ki ustreza vašemu union da spremljate, s kakšnimi podatki trenutno delate, na primer:

 struct { int oznaka; unija { long long int JulianDayNumer; signed char* CustomerName; } podatki; } vrednost;

Morda se boste odločili, ko value.tag nastavljena na 0, podatki še niso inicializirani za uporabo, 1 pomeni, da shranjujete datum, 2 pomeni, da je pomnilniški naslov, karkoli drugega pa pomeni napako.

No, bolje, da ne dovolite, da bi se kdo drug zapletel s tem value.tag ali pa bi se lahko vaš program dramatično slabo obnašal.

Bolj zaskrbljujoč primer bi lahko bil nekaj takega:

 struct { int oznaka; // 1 = razpršitev, 2 = unija funkcijskih kazalcev { nepredznačeni razpršitev char[16]; // bodisi shrani naključno zgoščeno strukturo { void* openfunc; // ali dva skrbno preverjena void* closefunc; // kazalci kode za kasnejšo izvedbo } validate; } } vrednost;

Zdaj preobremenimo isti blok pomnilnika, tako da ga lahko včasih uporabimo za shranjevanje 16-bajtne zgoščene vrednosti, včasih pa za shranjevanje dveh 8-bajtnih kazalcev na funkcije, ki jih bo naš program poklical pozneje.

Jasno, kdaj value.tag == 1, bi z veseljem dovolili, da bi naša programska oprema shranila kakršen koli 16-bajtni niz v pomnilnik, dodeljen za združevanje, ker so zgoščene vrednosti psevdonaključne, zato je vsaka zbirka bajtov enako verjetna.

Ampak ko value.tag == 2, bi morala biti naša koda izjemno previdna, da uporabniku ne bi dovolila, da posreduje nepreverjene, nezaupljive in neznane naslove funkcij za kasnejšo izvedbo.

Zdaj pa si predstavljajte, da bi lahko tej kodi predložili vrednost, medtem ko je bila oznaka nastavljena na 1, tako da ni bila preverjena in potrjena ...

... toda kasneje, tik preden je program dejansko uporabil shranjeno vrednost, ste lahko kodo preslepili, da je oznako preklopila na 2.

Koda bi nato sprejela vaše nepreverjene naslove funkcij kot "znane in že preverjeno varne" (čeprav to niso bili) in bi zanesljivo poslala izvajanje programa na lažno lokacijo v pomnilniku, ki ste jo zahrbtno izbrali vnaprej.

In to je tisto, kar se zgodi pri hrošču zmede tipa, čeprav z uporabo izmišljenega in poenostavljenega primera,

Pomnilnik, ki bi ga bilo varno porabiti, če bi z njim ravnali na en način, je zlonamerno dostavljen programu za obdelavo na alternativni, nevaren način.

Kaj storiti?

Preverite, ali imate najnovejšo različico Chroma ali Chromiuma.

Želite Chrome 114.0.5735.106 ali novejše v sistemih Mac in Linux ter 114.0.5735.110 ali novejši v sistemu Windows.

Ta napaka vpliva tudi na Microsoft Edge, ki temelji na Chromiumu.

Microsoft je doslej [2023-06-06T16:25:00Z] ugotovil, da

Microsoft se zaveda nedavnih izkoriščanj, ki obstajajo v naravi. Aktivno delamo na izdaji varnostnega popravka.

Edge je trenutno v različici 114.0.1823.37, tako da je vse oštevilčeno kasneje kot to mora vključevati Microsoftove popravke CVE-2023-3079.

Če želite preveriti svojo različico in vsiliti posodobitev, če je še niste prejeli:

  • Google Chrome. Meni s tremi pikami (⋮) > pomaga > O Chromu.
  • Microsoft Edge. Nastavitve in še več (…) > Pomoč in povratne informacije > O programu Microsoft Edge.

Ni za kaj.

Časovni žig:

Več od Gola varnost