Chrome zero-day: "Denna exploatering är i naturen", så kontrollera din version nu

Chrome zero-day: "Denna exploatering är i naturen", så kontrollera din version nu

Tidsstämpel: 6 juni 2023 12:28
Källnod: 2704382
by

Googles senaste Chrome-uppdatering är ute, och den här gången företaget har inte skrämt sina ord om en av de två säkerhetskorrigeringar som den innehåller:

Google är medvetet om att en exploatering för CVE-2023-3079 finns i det vilda.

Det finns ingen två-graders-separation, som vi ofta sett från Google tidigare, för att säga att företaget "är medvetet om rapporter" om en exploatering.

Den här gången är det "vi är medvetna om allt själva", vilket kan översättas ännu mer rakt av till "vi vet att skurkar missbrukar detta medan vi pratar", med tanke på att felrapporten kom direkt från Googles egen Threat Research Group.

Som vanligt innebär detta att Google undersökte en aktiv attack (antingen mot Google själv eller någon extern organisation, vi vet inte) där Chrome hade drabbats av ett tidigare okänt säkerhetshål.

Felet beskrivs enkelt som: Typ Confusion i V8. (Förståeligt nog säger Google inte mer än så i detta skede.)

Som vi har förklarat tidigare, a typ förvirring bugg inträffar när du förser ett program med en bit data som det är tänkt att tolka, validera, bearbeta och och agera på på ett sätt...

…men du lyckas senare lura programmet att tolka data på ett annat, obehörigt, ovaliderat och potentiellt farligt sätt.

Typförvirringsfaror förklaras

Föreställ dig att du skriver ett program i C. (Det spelar ingen roll om du kan C eller inte, du kan bara följa med ändå.)

I C deklarerar man vanligtvis variabler individuellt och reserverar alltså inte bara minne där de kan lagras, utan signalerar också till programmet hur dessa variabler ska användas.

Till exempel:

 lång lång int JulianDayNumber; undertecknad char* Kundnamn;

Den första variabeldeklarationen reserverar 64 bitar för att lagra ett vanligt gammalt heltalsvärde som representerar det astromonomiska dagtalet. (Om du undrar, i eftermiddag är JDN 23157 – Julian Days börjar vid middagstid, inte midnatt, eftersom astronomer ofta arbetar på natten, med midnatt som mitt på arbetsdagen.)

Den andra reserverar 64 bitar för att lagra en minnesadress där textsträngen för en kunds namn kan hittas.

Som du kan föreställa dig bör du inte blanda ihop dessa två värden, eftersom ett tal som är vettigt och säkert att använda som ett dagnummer, till exempel 23157, skulle nästan säkert vara osäkert att använda som minnesadress.

Som du kan se från denna minnesdump av ett Windows-program som körs, börjar den lägsta minnesadressen som är tilldelad för användning kl. 0x00370000, vilket är 3,604,480 XNUMX XNUMX i decimal, mycket större än något vettigt dagtal.

De faktiska minnesadresserna som används av Windows varierar slumpmässigt över tiden, för att göra din minneslayout svårare för skurkar att gissa, så om du skulle köra samma program skulle du få värden, men de kommer ändå att vara liknande:

Och (även om det är längst ner på bilden ovan) minnesadresserna för runtime användardatasektionen när det här programmet kördes från 0x01130000 till 0x01134FFF, som representerar det osannolika datumintervallet 22 juli 44631 till 16 augusti 44687.

Faktum är att om du försöker blanda de två variablerna, bör kompilatorn försöka varna dig, till exempel så här:

 JulianDayNumber = Kundnamn; CustomerName = JulianDayNumber; varning: tilldelning gör heltal från pekare utan cast varning: tilldelning gör pekare från heltal utan cast

Nu, om du någonsin har programmerat i C, vet du att du för enkelhetens skull kan deklarera variabler med flera olika tolkningar med hjälp av union nyckelord, så här:

 union { long long int JulianDayNumer; undertecknad char* Kundnamn; } data;

Du kan nu referera till exakt samma variabel i minnet på två olika sätt.

Om du skriver data.JulianDayNumber, tolkar du den lagrade datan som ett heltal, men skriver data.CustomerName talar om för kompilatorn att du refererar till en minnesadress, även om du har åtkomst till samma lagrade data.

Vad du gör, mer eller mindre, är att erkänna för kompilatorn att du ibland kommer att behandla data du har som ett datum, och andra gånger som en minnesadress, och att du tar ansvar för att komma ihåg vilken tolkning som gäller vid vilken tidpunkt i koden.

Du kanske väljer att ha en andra variabel, känd som en tag (vanligtvis ett heltal) för att följa med din union för att hålla reda på vilken typ av data du arbetar med just nu, till exempel:

 struct { int tag; union { long long int JulianDayNumer; undertecknad char* Kundnamn; } data; } värde;

Du kan bestämma när value.tag är inställd på 0, informationen är inte initierad för användning ännu, 1 betyder att du lagrar ett datum, 2 betyder att det är en minnesadress, och allt annat anger ett fel.

Tja, det är bäst att du inte låter någon annan bråka med det value.tag inställning, eller så kan ditt program sluta uppföra sig dramatiskt.

Ett mer oroande exempel kan vara något i stil med detta:

 struct { int tag; // 1 = hash, 2 = function pointers union { unsigned char hash[16]; // lagra antingen en slumpmässig hash-struktur { void* openfunc; // eller två noggrant validerade void* closefunc; // kodpekare att köra senare } validera; } } värde;

Nu överbelastar vi samma minnesblock så att vi ibland kan använda det för att lagra en 16-byte hash, och ibland för att lagra två 8-byte pekare till funktioner som vårt program kommer att anlita senare.

Klart när value.tag == 1, vi skulle gärna låta vår programvara lagra vilken 16-byte-sträng som helst i minnet som allokerats för unionen, eftersom hash är pseudoslumpmässiga, så varje samling av byte är lika sannolikt.

Men när value.tag == 2, skulle vår kod behöva vara extra noggrann för att inte tillåta användaren att tillhandahålla ovaliderade, opålitliga, okända funktionsadresser för att köra senare.

Föreställ dig nu att du kunde skicka ett värde till den här koden medan taggen var inställd på 1, så att den inte blev kontrollerad och validerad...

…men senare, precis innan programmet faktiskt använde det lagrade värdet, kunde du lura koden att byta taggen till 2.

Koden skulle sedan acceptera dina ovaliderade funktionsadresser som "kända och redan verifierade säkra" (även om de inte var det), och skulle på ett förtroendefullt sätt skicka programkörning till en falsk plats i minnet som du smygt hade valt i förväg.

Och det är vad som händer i en typförvirringsbugg, om än med ett konstruerat och förenklat exempel,

Minne som skulle vara säkert att konsumera om det hanterades på ett sätt levereras med uppsåt till programmet för att bearbeta på ett alternativt, osäkert sätt.

Vad göra?

Se till att du har den senaste versionen av Chrome eller Chromium.

Du vill ha Chrome 114.0.5735.106 eller senare på Mac och Linux, och 114.0.5735.110 eller senare på Windows.

Microsoft Edge, som är baserad på Chromium, påverkas också av denna bugg.

Microsoft har hittills [2023-06-06T16:25:00Z] noterade det

Microsoft är medvetet om de senaste bedrifterna som finns i naturen. Vi arbetar aktivt med att släppa en säkerhetsuppdatering.

Edge har för närvarande version 114.0.1823.37, så allt är numrerat senare än så bör inkludera Microsofts CVE-2023-3079 patchar.

Så här kontrollerar du din version och tvingar fram en uppdatering om det finns en som du inte har fått ännu:

  • Google Chrome Trepricksmeny (⋮) > Hjälp > Om Chrome.
  • Microsoft Edge. Inställningar och mer (...) > Hjälp och feedback > Om Microsoft Edge.

Varsågod.

Tidsstämpel:

Mer från Naken säkerhet