Megjelent a Google legújabb Chrome-frissítése, és ezúttal a cég nem aprózta el a szavait a két biztonsági javítás közül az egyiket tartalmazza:
A Google tisztában van azzal, hogy egy kizsákmányolás a CVE-2023 3079- a vadonban létezik.
Nincs kétfokozatú elválasztás, ahogyan azt a Google-tól korábban gyakran láthattuk, hogy a vállalat „tudatában van a visszaélésekről szóló jelentéseknek”.
Ezúttal a „mi magunk is tisztában vagyunk ezzel”, ami még egyenesebben azt jelenti, hogy „tudjuk, hogy a szélhámosok visszaélnek ezzel, miközben beszélünk”, tekintve, hogy a hibajelentés közvetlenül a Google saját Fenyegetéskutató Csoportjától érkezett.
Ez szokás szerint azt jelenti, hogy a Google egy aktív támadást vizsgált (akár maga a Google, akár valamilyen külső szervezet ellen, nem tudjuk), amelyben a Chrome-ot egy korábban ismeretlen biztonsági rés ütötte meg.
A hibát egyszerűen a következőképpen írják le: Írja be a Zavart a V8-ban. (Érthető, hogy a Google ennél többet nem mond ebben a szakaszban.)
Amint azt korábban kifejtettük, a típusú zavartság hiba akkor fordul elő, ha egy programhoz olyan adattömeget szolgáltat, amelyet egyféle módon kell elemeznie, érvényesítenie, feldolgoznia és cselekednie…
…de később sikerül rávennie a programot, hogy az adatokat más, jogosulatlan, nem érvényesített és potenciálisan veszélyes módon értelmezze.
A típuszavaros veszélyek magyarázata
Képzeld el, hogy C-ben írsz egy programot. (Nem számít, hogy tudod-e a C-t vagy sem, úgyis követheted.)
A C-ben általában egyenként deklarálunk változókat, így nem csak a memóriát foglaljuk le, ahol tárolhatók, hanem jelezzük a programnak, hogy ezeket a változókat hogyan kell használni.
Például:
long long int JulianDayNumber; aláírt karakter* Ügyfélnév;
Az első változódeklaráció 64 bitet tart fenn egy sima régi egész érték tárolására, amely a csillagászati napszámot reprezentálja. (Ha kíváncsi, ma délután a JDN 23157 – a Julian Days délben kezdődik, nem éjfélkor, mert a csillagászok gyakran éjszaka dolgoznak, és az éjfél a munkanapjuk közepe.)
A második 64 bitet tart fenn egy memóriacím tárolására, ahol az ügyfél nevének szöveges karakterlánca megtalálható.
Elképzelhető, hogy jobb, ha nem keveri össze ezt a két értéket, mert egy olyan számot, amely logikus és biztonságos napszámként használni, mint például a 23157, szinte biztosan nem lenne biztonságos memóriacímként használni.
Amint egy futó Windows program memóriakiírásából látható, a használatra lefoglalt legalacsonyabb memóriacím 0x00370000, ami tizedesjegyben 3,604,480 XNUMX XNUMX, sokkal nagyobb, mint bármely értelmes napszám.
A Windows által használt tényleges memóriacímek véletlenszerűen változnak az idő múlásával, hogy nehezítsék kitalálni a memóriaelrendezést, így ha ugyanazt a programot futtatná, értékeket kapna, de ezek hasonlóak lesznek:
És (bár a fenti kép alján látható) a futásidejű felhasználói adatok szakasz memóriacímei, amikor a program futott 0x01130000 nak nek 0x01134FFF, amely a 22. július 44631. és 16. augusztus 44687. közötti valószínűtlen dátumtartományt jelenti.
Valójában, ha megpróbálja összekeverni ezt a két változót, a fordítónak meg kell próbálnia figyelmeztetni, például így:
JulianDayNumber = Ügyfélnév; Ügyfélnév = JulianDayNumber; Figyelmeztetés: a hozzárendelés egész számot hoz a mutatóból átadási figyelmeztetés nélkül: a hozzárendelés egész számból mutatót cast nélkül
Ha már programozott C nyelven, akkor tudni fogja, hogy a kényelem kedvéért több különböző értelmezésű változót deklarálhat a union kulcsszó, például így:
union { long long int JulianDayNumer; aláírt karakter* Ügyfélnév; } adat;
Most már két különböző módon hivatkozhat pontosan ugyanarra a változóra a memóriában.
Ha írsz data.JulianDayNumber, varázslatosan egész számként értelmezed a tárolt adatokat, de írás data.CustomerName közli a fordítóval, hogy egy memóriacímre hivatkozik, még akkor is, ha ugyanazokhoz a tárolt adatokhoz fér hozzá.
Amit csinálsz, többé-kevésbé az az, hogy elismered a fordítónak, hogy a megszerzett adatokat néha dátumként, máskor memóriacímként kezeled, és felelősséget vállal azért, hogy emlékezzen, melyik értelmezés melyik pillanatban érvényes a kódot.
Dönthet úgy, hogy egy második változót, az a tag (általában egész szám), hogy együtt járjon a sajátjával union nyomon követni, hogy éppen milyen típusú adatokkal dolgozik, például:
struct { int tag; union { long long int JulianDayNumer; aláírt karakter* Ügyfélnév; } adat; } érték;
Lehet, hogy te döntöd el, hogy mikor value.tag be van állítva 0, az adatok még nincsenek inicializálva használatra, 1 azt jelenti, hogy eltárol egy dátumot, 2 azt jelenti, hogy ez egy memóriacím, és bármi más hibát jelez.
Nos, jobb, ha nem hagyod, hogy senki más ezzel foglalkozzon value.tag beállítást, különben a program drámaian rosszul fog működni.
Aggasztóbb példa lehet valami ilyesmi:
struct { int tag; // 1 = hash, 2 = függvénymutatók union { unsigned char hash[16]; // vagy tárol egy véletlenszerű hash struct { void* openfunc; // vagy két gondosan érvényesített void* closefunc; // kódmutatók későbbi végrehajtáshoz } validate; } } érték;
Most túlterheljük ugyanazt a memóriablokkot, így néha 16 bájtos hash tárolására használhatjuk, néha pedig két 8 bájtos mutató tárolására olyan függvényekre, amelyeket a programunk később hívni fog.
Egyértelmű, hogy mikor value.tag == 1, szívesen hagynánk, hogy szoftverünk bármilyen 16 bájtos karakterláncot tároljon az unió számára lefoglalt memóriában, mivel a hash-ek álvéletlenek, így minden bájtgyűjtemény ugyanolyan valószínű.
De amikor value.tag == 2, a kódunknak rendkívül óvatosnak kell lennie, hogy a felhasználó ne adjon meg nem érvényesített, nem megbízható, ismeretlen függvénycímeket a későbbi végrehajtáshoz.
Most képzelje el, hogy megadhat egy értéket ennek a kódnak, miközben a címke 1-re van állítva, így nem lett ellenőrizve és érvényesítve…
…de később, közvetlenül azelőtt, hogy a program ténylegesen felhasználta volna a tárolt értéket, sikerült rávenni a kódot, hogy a címkét 2-re váltsa.
A kód ezután „ismert és már ellenőrzött biztonságosként” fogadja el az Ön nem érvényesített funkciócímeit (még ha nem is azok), és megbízhatóan elküldi a program végrehajtását a memória egy rosszindulatú helyére, amelyet Ön titokban előre kiválasztott.
És ez történik egy típuszavaros hiba esetén, bár egy kiagyalt és leegyszerűsített példát használva,
Az egyfajta kezelés esetén biztonságosan fogyasztható memória rosszindulatúan a programhoz kerül, hogy egy alternatív, nem biztonságos módon dolgozza fel.
Mit kell tenni?
Győződjön meg arról, hogy a Chrome vagy a Chromium legújabb verzióját használja.
Chrome-ot akarsz 114.0.5735.106 vagy újabb Mac és Linux rendszeren, és 114.0.5735.110 vagy újabb Windows rendszeren.
A Chromium alapú Microsoft Edge-t is érinti ez a hiba.
A Microsoft eddig [2023-06-06T16:25:00Z] észrevettem
A Microsoft tisztában van a vadon élő közelmúltbeli kihasználásokkal. Aktívan dolgozunk egy biztonsági javítás kiadásán.
Az Edge jelenleg a 114.0.1823.37-es verziónál fut, tehát bármi számozott később annál tartalmaznia kell a Microsoft CVE-2023-3079 javításait.
A verzió ellenőrzéséhez és a frissítés kényszerítéséhez, ha még nem kapott meg egy frissítést:
- Google Chrome. Hárompontos menü (⋮) > Segítség > A Chrome-ról.
- Microsoft Edge. Beállítások stb (…) > Segítség és visszajelzés > A Microsoft Edge-ről.
Szívesen.
- SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
- PlatoAiStream. Web3 adatintelligencia. Felerősített tudás. Hozzáférés itt.
- A jövő pénzverése – Adryenn Ashley. Hozzáférés itt.
- Részvények vásárlása és eladása PRE-IPO társaságokban a PREIPO® segítségével. Hozzáférés itt.
- Forrás: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/