Googles seneste Chrome-opdatering er ude, og denne gang virksomheden har ikke skåret sine ord om en af de to sikkerhedsrettelser, den indeholder:
Google er klar over, at en udnyttelse af CVE-2023-3079 findes i naturen.
Der er ikke tale om to-graders adskillelse, som vi ofte har set fra Google før, for at sige, at virksomheden "er opmærksom på rapporter" om en udnyttelse.
Denne gang er det "vi er klar over det hele af os selv", hvilket oversættes endnu mere direkte til "vi ved, at skurke misbruger dette, mens vi taler", givet at fejlrapporten kom direkte fra Googles egen Threat Research Group.
Som sædvanligt indebærer dette, at Google undersøgte et aktivt angreb (om det er mod Google selv eller en ekstern organisation, vi ved det ikke), hvor Chrome var blevet ramt af et hidtil ukendt sikkerhedshul.
Fejlen beskrives ganske enkelt som: Type Confusion i V8. (Forståeligt nok siger Google ikke mere end det på nuværende tidspunkt.)
Som vi har forklaret før, a type forvirring fejl opstår, når du forsyner et program med en del af data, som det skal parse, validere, behandle og og handle på én måde...
…men det lykkes dig senere at narre programmet til at fortolke dataene på en anden, uautoriseret, uvalideret og potentielt farlig måde.
Farer for typeforvirring forklaret
Forestil dig, at du skriver et program i C. (Det er lige meget om du kan C eller ej, du kan bare følge med alligevel.)
I C deklarerer man normalt variabler individuelt, således at man ikke kun reserverer hukommelse, hvor de kan gemmes, men signalerer også til programmet, hvordan disse variabler skal bruges.
For eksempel:
lang lang int JulianDagNumber; underskrevet char* Kundenavn;
Den første variabeldeklaration reserverer 64 bit til lagring af en almindelig gammel heltalværdi, der repræsenterer det astromonomiske dagnummer. (Hvis du undrer dig, er denne eftermiddag JDN 23157 – Julianske dage starter ved middagstid, ikke midnat, fordi astronomer ofte arbejder om natten, hvor midnat er midt på deres arbejdsdag.)
Den anden reserverer 64 bit til lagring af en hukommelsesadresse, hvor tekststrengen i en kundes navn kan findes.
Som du kan forestille dig, må du hellere ikke blande disse to værdier, fordi et tal, der giver mening og er sikkert at bruge som et dagnummer, såsom 23157, ville næsten helt sikkert være usikkert at bruge som hukommelsesadresse.
Som du kan se fra dette hukommelsesdump af et kørende Windows-program, starter den laveste hukommelsesadresse, der er tildelt til brug kl. 0x00370000, hvilket er 3,604,480 i decimal, langt større end noget fornuftigt dagtal.
De faktiske hukommelsesadresser, der bruges af Windows, varierer tilfældigt over tid, for at gøre dit hukommelseslayout sværere for skurke at gætte, så hvis du skulle køre det samme program, ville du få værdier, men de vil ikke desto mindre være ens:
Og (selvom det er ude af bunden af billedet ovenfor) hukommelsesadresserne for runtime-brugerdatasektionen, da dette program kørte fra 0x01130000 til 0x01134FFF, der repræsenterer det usandsynlige datointerval fra 22. juli 44631 til 16. august 44687.
Faktisk, hvis du prøver at blande disse to variabler, bør compileren forsøge at advare dig, for eksempel sådan her:
JulianDayNumber = Kundenavn; CustomerName = JulianDayNumber; advarsel: tildeling laver et heltal fra pointer uden en cast advarsel: opgave laver pointer fra et heltal uden en cast
Nu, hvis du nogensinde har programmeret i C, vil du vide, at du for nemheds skyld kan erklære variabler med flere forskellige fortolkninger ved hjælp af union søgeord, som dette:
union { long long int JulianDayNumer; underskrevet char* Kundenavn; } data;
Du kan nu referere til nøjagtig den samme variabel i hukommelsen på to forskellige måder.
Hvis du skriver data.JulianDayNumber, fortolker du på magisk vis de lagrede data som et heltal, men skriver data.CustomerName fortæller compileren, at du refererer til en hukommelsesadresse, selvom du har adgang til de samme lagrede data.
Det, du mere eller mindre gør, er at indrømme over for compileren, at du nogle gange behandler de data, du har, som en dato, og andre gange som en hukommelsesadresse, og at du tager ansvar for at huske, hvilken fortolkning der gælder på hvilket tidspunkt i koden.
Du kan beslutte at have en anden variabel, kendt som en tag (typisk et heltal) for at gå sammen med din union for at holde styr på, hvilken slags data du arbejder med lige nu, for eksempel:
struct { int tag; union { long long int JulianDayNumer; underskrevet char* Kundenavn; } data; } værdi;
Du kan bestemme hvornår value.tag er sat til 0, dataene er ikke initialiseret til brug endnu, 1 betyder, at du gemmer en dato, 2 betyder, at det er en hukommelsesadresse, og alt andet angiver en fejl.
Nå, du må hellere ikke lade nogen andre rode med det value.tag indstilling, eller dit program kan ende med at opføre sig dramatisk.
Et mere bekymrende eksempel kunne være noget som dette:
struct { int tag; // 1 = hash, 2 = function pointers union { unsigned char hash[16]; // enten gemmer en tilfældig hash-struktur { void* openfunc; // eller to omhyggeligt validerede void* closefunc; // kode pointere til at udføre senere } validere; } } værdi;
Nu overbelaster vi den samme hukommelsesblok, så vi nogle gange kan bruge den til at gemme en 16-byte hash, og nogle gange til at gemme to 8-byte pointere til funktioner, som vores program vil kalde på senere.
Det er klart, hvornår value.tag == 1, vil vi med glæde lade vores software gemme enhver 16-byte streng overhovedet i den hukommelse, der er allokeret til foreningen, fordi hashes er pseudorandom, så enhver samling af bytes er lige så sandsynlig.
Men når value.tag == 2, skal vores kode være ekstra-super forsigtig for ikke at tillade brugeren at give uvaliderede, upålidelige, ukendte funktionsadresser til at udføre senere.
Forestil dig nu, at du kunne indsende en værdi til denne kode, mens taggen var sat til 1, så den ikke blev kontrolleret og valideret...
…men senere, lige før programmet rent faktisk brugte den lagrede værdi, var du i stand til at narre koden til at skifte taggen til 2.
Koden ville derefter acceptere dine uvaliderede funktionsadresser som "kendte og allerede verificerede sikre" (selvom de ikke var det), og ville tillidsfuldt sende programudførelse til en falsk placering i hukommelsen, som du lusket havde valgt på forhånd.
Og det er, hvad der sker i en typeforvirringsfejl, omend ved at bruge et konstrueret og forenklet eksempel,
Hukommelse, der ville være sikker at forbruge, hvis den blev håndteret på én måde, er ondsindet leveret til programmet for at behandle på en alternativ, usikker måde.
Hvad skal jeg gøre?
Sørg for, at du har den nyeste version af Chrome eller Chromium.
Du vil have Chrome 114.0.5735.106 eller nyere på Mac og Linux, og 114.0.5735.110 eller nyere på Windows.
Microsoft Edge, som er baseret på Chromium, er også påvirket af denne fejl.
Microsoft har indtil videre [2023-06-06T16:25:00Z] bemærkede det
Microsoft er opmærksom på de seneste udnyttelser, der eksisterer i naturen. Vi arbejder aktivt på at frigive en sikkerhedspatch.
Edge er i øjeblikket på version 114.0.1823.37, så alt er nummereret senere end det bør inkludere Microsofts CVE-2023-3079 patches.
Sådan tjekker du din version og fremtvinger en opdatering, hvis der er en, du ikke har modtaget endnu:
- Google Chrome. Menu med tre prikker (⋮) > Hjælp > Om Chrome.
- Microsoft Edge. Indstillinger og mere (...) > Hjælp og feedback > Om Microsoft Edge.
Selv tak.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoAiStream. Web3 Data Intelligence. Viden forstærket. Adgang her.
- Udmøntning af fremtiden med Adryenn Ashley. Adgang her.
- Køb og sælg aktier i PRE-IPO-virksomheder med PREIPO®. Adgang her.
- Kilde: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/