Googles siste Chrome-oppdatering er ute, og denne gangen selskapet har ikke skåret ordene om en av de to sikkerhetsoppdateringene den inkluderer:
Google er klar over at en utnyttelse for CVE-2023-3079 finnes i naturen.
Det er ingen to-graders-separasjon, som vi ofte har sett fra Google før, for å si at selskapet "er klar over rapporter" om en utnyttelse.
Denne gangen er det «vi er klar over alt selv», som oversettes enda mer rett ut til «vi vet at skurker misbruker dette mens vi snakker», gitt at feilrapporten kom direkte fra Googles egen Threat Research Group.
Som vanlig antyder dette at Google undersøkte et aktivt angrep (enten mot Google selv, eller en ekstern organisasjon, vi vet ikke) der Chrome var blitt utsatt for et tidligere ukjent sikkerhetshull.
Feilen beskrives ganske enkelt som: Type Confusion i V8. (Forståelig nok, Google sier ikke mer enn det på dette stadiet.)
Som vi har forklart før, a type forvirring feil oppstår når du forsyner et program med en mengde data som det er ment å analysere, validere, behandle og og handle ut fra på én måte...
…men du klarer senere å lure programmet til å tolke dataene på en annen, uautorisert, uvalidert og potensielt farlig måte.
Typeforvirringsfarer forklart
Tenk deg at du skriver et program i C. (Det spiller ingen rolle om du kan C eller ikke, du kan bare følge med uansett.)
I C erklærer du vanligvis variabler individuelt, og reserverer dermed ikke bare minnet der de kan lagres, men signaliserer også til programmet hvordan disse variablene skal brukes.
For eksempel:
lang lang int JulianDayNumber; signert tegn* Kundenavn;
Den første variabeldeklarasjonen reserverer 64 biter for lagring av en vanlig, gammel heltallsverdi som representerer det astromonomiske dagtallet. (Hvis du lurer, er denne ettermiddagen JDN 23157 – Julian Days starter ved middagstid, ikke midnatt, fordi astronomer ofte jobber om natten, med midnatt som midt på arbeidsdagen.)
Den andre reserverer 64 biter for å lagre en minneadresse der tekststrengen til en kundes navn kan finnes.
Som du kan forestille deg, bør du ikke blande disse to verdiene, fordi et tall som er fornuftig og trygt å bruke som dagnummer, for eksempel 23157, vil nesten helt sikkert være utrygt å bruke som minneadresse.
Som du kan se fra denne minnedumpen til et Windows-program som kjører, starter den laveste minneadressen som er tildelt for bruk kl. 0x00370000, som er 3,604,480 XNUMX XNUMX i desimal, mye større enn noe fornuftig dagtall.
De faktiske minneadressene som brukes av Windows varierer tilfeldig over tid, for å gjøre minneoppsettet ditt vanskeligere for kjeltringer å gjette, så hvis du skulle kjøre det samme programmet, ville du få verdier, men de vil likevel være like:
Og (selv om det er utenfor bunnen av bildet ovenfor) minneadressene til runtime brukerdataseksjonen da dette programmet kjørte fra 0x01130000 til 0x01134FFF, som representerer det usannsynlige datointervallet 22. juli 44631 til 16. august 44687.
Faktisk, hvis du prøver å blande disse to variablene, bør kompilatoren prøve å advare deg, for eksempel slik:
JulianDayNumber = Kundenavn; CustomerName = JulianDayNumber; advarsel: oppgave lager heltall fra peker uten cast advarsel: oppgave lager peker fra heltall uten cast
Nå, hvis du noen gang har programmert i C, vil du vite at du for enkelhets skyld kan deklarere variabler med flere forskjellige tolkninger ved å bruke union nøkkelord, som dette:
union { long long int JulianDayNumer; signert tegn* Kundenavn; } data;
Du kan nå referere til nøyaktig samme variabel i minnet på to forskjellige måter.
Hvis du skriver data.JulianDayNumber, tolker du på magisk vis de lagrede dataene som et heltall, men skriver data.CustomerName forteller kompilatoren at du refererer til en minneadresse, selv om du har tilgang til de samme lagrede dataene.
Det du gjør, mer eller mindre, er å innrømme overfor kompilatoren at du noen ganger vil behandle dataene du har som en dato, og andre ganger som en minneadresse, og at du tar ansvar for å huske hvilken tolkning som gjelder i hvilket øyeblikk i koden.
Du kan bestemme deg for å ha en annen variabel, kjent som en tag (vanligvis et heltall) for å gå sammen med din union for å holde styr på hva slags data du jobber med akkurat nå, for eksempel:
struct { int tag; union { long long int JulianDayNumer; signert tegn* Kundenavn; } data; } verdi;
Du kan bestemme når value.tag er satt til 0, dataene er ikke initialisert for bruk ennå, 1 betyr at du lagrer en dato, 2 betyr at det er en minneadresse, og alt annet angir en feil.
Vel, du bør ikke la noen andre rote med det value.tag innstilling, eller programmet kan ende opp med å oppføre seg dramatisk.
Et mer bekymringsfullt eksempel kan være noe sånt som dette:
struct { int tag; // 1 = hash, 2 = function pointers union { unsigned char hash[16]; // lagre enten en tilfeldig hash-struktur { void* openfunc; // eller to nøye validerte void* closefunc; // kodepekere for å utføre senere } validere; } } verdi;
Nå overbelaster vi den samme minneblokken, slik at vi noen ganger kan bruke den til å lagre en 16-byte hash, og noen ganger til å lagre to 8-byte pekere til funksjoner som programmet vårt vil bruke senere.
Klart når value.tag == 1, vil vi gjerne la programvaren vår lagre en hvilken som helst 16-byte-streng i det hele tatt i minnet som er allokert for unionen, fordi hashes er pseudorandom, så enhver samling av byte er like sannsynlig.
Men når value.tag == 2, må koden vår være ekstra forsiktig for ikke å la brukeren oppgi uvaliderte, uklarerte, ukjente funksjonsadresser for å utføre senere.
Tenk deg nå at du kan sende inn en verdi til denne koden mens taggen var satt til 1, slik at den ikke ble sjekket og validert...
…men senere, rett før programmet faktisk brukte den lagrede verdien, kunne du lure koden til å bytte taggen til 2.
Koden ville da godta de uvaliderte funksjonsadressene dine som "kjente og allerede verifiserte trygge" (selv om de ikke var det), og ville på en tillitsfull måte sende programkjøring til en falsk plassering i minnet som du hadde valgt på forhånd.
Og det er det som skjer i en type forvirringsfeil, om enn ved å bruke et konstruert og forenklet eksempel,
Minne som ville være trygt å konsumere hvis det ble håndtert på en måte, ble levert til programmet på en annen måte for å behandle det på en alternativ, usikker måte.
Hva gjør jeg?
Sørg for at du har den nyeste versjonen av Chrome eller Chromium.
Du vil ha Chrome 114.0.5735.106 eller senere på Mac og Linux, og 114.0.5735.110 eller nyere på Windows.
Microsoft Edge, som er basert på Chromium, er også berørt av denne feilen.
Microsoft har så langt [2023-06-06T16:25:00Z] bemerket det
Microsoft er klar over de nylige utnyttelsene som eksisterer i naturen. Vi jobber aktivt med å gi ut en sikkerhetsoppdatering.
Edge er for øyeblikket på versjon 114.0.1823.37, så alt er nummerert senere enn det bør inkludere Microsofts CVE-2023-3079-oppdateringer.
For å sjekke versjonen din og tvinge frem en oppdatering hvis det er en du ikke har mottatt ennå:
- Google Chrome. Meny med tre prikker (⋮) > Hjelp > Om Chrome.
- Microsoft Edge. Innstillinger og mer (...) > Hjelp og tilbakemeldinger > Om Microsoft Edge.
Værsågod.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoAiStream. Web3 Data Intelligence. Kunnskap forsterket. Tilgang her.
- Minting the Future med Adryenn Ashley. Tilgang her.
- Kjøp og selg aksjer i PRE-IPO-selskaper med PREIPO®. Tilgang her.
- kilde: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/